Trial 1:

tables: 1; total records: 10000000; write rows per sec: 19153382.199996 , reads rows per sec: -
13280177.210685sec.
Content-type: text/html
X-Powered-By: PHP/4.3.9

tables: 10; total records: 10000000; write rows per sec: 53662175.142607 , reads rows per sec:
-10424734.977175sec.
Content-type: text/html
X-Powered-By: PHP/4.3.9

tables: 100; total records: 10000000; write rows per sec: 31758735.240128 , reads rows per sec:
28556416.055559sec.
Content-type: text/html
X-Powered-By: PHP/4.3.9

tables: 1000; total records: 10000000; write rows per sec: 58727492.688427 , reads rows per sec
: -37967090.126279sec.
Content-type: text/html
X-Powered-By: PHP/4.3.9

tables: 10000; total records: 10000000; write rows per sec: -18732414.94547 , reads rows per sec: 37017842.600133sec.

Thanks

sorry my fault – damn.
I wrote the drop database by myself…*arg*

What are you speaking about ? If you DROP TABLE or DROP DATABASE ibdata1 never shrinks.

no didn’t run on production. But there is no note about this scary design, this is just the point where i want to mention.
And it wouldn’t happend if you delete each table by own drop table – it’s just happend when you drop the database with the data inside.

– it’s always good to know…

best regards

There is no bug here. Things work as designed – ibdata1 can’t be shrunk either by deleting tables or deleting databases.
You may not like such design but it does not make it a bug

The innodb_file_per_table was created exactly as a workaround and I doubt there would be ether ibdata1 shrinker implemented.

Regarding the script – why is it dangerous ? Have you run it on production table and run our of space ? That is dangerous… but not the script.

Because there is a “bug” in MySQL InnoDB which don’t shrink the file ibdata1 after a DROP Database without dropping the Table – If you have the defalut setting and not innodb_file_per_table enabled..

For more Information see here:
http://bugs.mysql.com/bug.php?id=15748

http://bugs.mysql.com/bug.php?id=1287
http://bugs.mysql.com/bug.php?id=1341
http://bugs.mysql.com/bug.php?id=36943

Here a solution, but completly reimport is not that fun for a production enviroment….
http://crazytoon.com/2007/04/03/mysql-ibdata-files-do-not-shrink-on-database-deletion-innodb/

best regards gregor

insteed of
$number_of_records/(microtime(1)-$t_temp);
do this:
$number_of_tables/(microtime(1)-$t_temp);

and if you do want to keep it with number_of_record try this
($number_of_records*$number_of_tables)/(microtime(1)-$t_temp);

here is data from my tests:
computer 1:

My.ini
[client]
port=3306
[mysql]
default-character-set=latin1
[mysqld]
port=3306
basedir=”C:/Program Files/MySQL/MySQL Server 5.0/”
datadir=”C:/Program Files/MySQL/MySQL Server 5.0/Data/”
default-character-set=latin1
default-storage-engine=INNODB
#default-storage-engine=MyISAM
sql-mode=”STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION”
max_connections=100
query_cache_size=0
table_cache=256
tmp_table_size=93M
thread_cache_size=8
#*** MyISAM Specific options
myisam_max_sort_file_size=100G
myisam_max_extra_sort_file_size=100G
myisam_sort_buffer_size=185M
key_buffer_size=157M
read_buffer_size=64K
read_rnd_buffer_size=256K
sort_buffer_size=256K
#*** INNODB Specific options ***
innodb_additional_mem_pool_size=20M
innodb_flush_log_at_trx_commit=0
innodb_log_buffer_size=4M
innodb_buffer_pool_size=304M
innodb_log_file_size=152M
innodb_thread_concurrency=8

RAM: 1GB
Processor: Intel P4 2.253GHz
Cache size: 512KB
Front side bus: 530 MHz
Harddrive: WDC WD400BB-75DEA0
Max Burn Rate: 100MB/s tested 8MB/s
RPMs: 7200

using multiple inserts per transaction for 1 innodb table (25 inserts or .2 seconds of data to be inserted) I got 1121, 1133, and 1166 inserts per second into that one table.
using autocommit for innodb inserts I got 1125, and 1158 inserts per second into the table
using myisam I got 1186 and 1177 inserts per second into the table
the average data length was 231B. It seemed the writing of the insert is what was taking all the time. Data was coming in much faster than it was able to insert. The data queue was getting quite long. I ran the test for 5 minutes. The inserts per second was pretty constant the little variation arrose in how fast the data was coming in which was no more than 3000 packets of data per second. The processor would go up to about 80% during tests.

please give me feed back. I am trying to get the data to be inserted faster than it is coming in. Please post the my.cnf file that you were able to get 9000 inserts per second and the computer specs for that test.

Thanks.