Giacomo Vacca

I wanted to create a MySQL dump of a small DB, so run  mysqldump  and realized that what I was expecting to take a few MB was instead half a GB. Where did things go wrong? Which table is storing such an unexpected amount of data? Googling around I've found a few interesting posts on how to check the size of a table, and then selected  this one . My suggested approach is: SELECT TABLE_NAME , table_rows , data_length , index_length , round ( ( ( data_length + index_length ) / 1024 / 1024 ) , 2 ) "Size in MB" FROM information_schema . TABLES WHERE table_schema = "schema_name" ; where schema_name is the DB you're interested in. I've then immediately spotted the "offending" table :-)

The first time I needed to have some kind of complex select statement, I started to pray about the ability to use regular expressions with mysql. Easy as it may be: use REGEXP ! For example: SELECT * FROM db.ip_addresses WHERE ip_address REGEXP '^192\.168\.0\.(133|135)$'; See the official documentation and details here .

If you want to know which is the ID of the last INSERT been made from the current connection, when auto_increment is active, use this: SELECT LAST_INSERT_ID(); A few lines in non-optimized perl: my $sel_last = "SELECT LAST_INSERT_ID();"; my $sth = $dbh->prepare($sel_last) or die "Couldn't prepare statement: " . $dbh->errstr; $sth->execute() or die "Couldn't execute statement: " . $sth->errstr; my @data; while (@data = $sth->fetchrow_array()) { print "Last ID was.... $data[0]"; } More details here for the MySQL statement and here for the perl DBI .