*I would not recommend* the [**MEMORY storage engine**][1] #REASON #1 : No Redundancy Whether you have a server crash or a normal system shutdown, all the data in the [MEMORY table][2] are lost. All you would have is the table structure. #REASON #2 : Mild Disk I/O No matter what Storage Engine you choose, the `.frm` of a table is always accessed to check for table existence and availability. This will incur some disk I/O for this check. Please read past posts on the pros and cons of the [MEMORY Storage Engine][3] - `May 22, 2011` : http://dba.stackexchange.com/questions/2868/i-am-using-the-memory-storage-engine-but-mysql-still-writes-to-my-disk-why/2876#2876 - `Sep 26, 2011` : http://dba.stackexchange.com/questions/6156/is-it-feasible-to-have-mysql-in-memory-storage-engine-utilize-512-gb-of-ram/6176#6176 - `Jan 17, 2012` : http://dba.stackexchange.com/questions/10806/mysql-memory-table-getting-many-locks/10821#10821 - `Jan 20, 2012` : http://dba.stackexchange.com/questions/11912/how-much-memory-will-a-memory-table-take-up/11917#11917 #RECOMMENDATION Given the two reasons for not using the MEMORY Storage Engine, I would recommend the [MyISAM][4] Storage Engine over using MEMORY or InnoDB. Why? Looking back at Reason #1, you can have everything in RAM and have data redundancy on disk if you create the table as follows: STEP 01) Create the table like this: CREATE TABLE blacklist ( url VARCHAR(20), dt DATETIME, PRIMARY KEY (url) ) ENGINE=MyISAM ROW_FORMAT=Fixed; STEP 02) Create a dedicated 16MB MyISAM cache for that table: cd /var/lib/mysql echo "SET GLOBAL blacklist_keycache.key_buffer_size = 1024 * 1024 * 16;" > init-file.sql echo "CACHE INDEX blacklist IN blacklist_keycache; >> init-file.sql echo "LOAD INDEX INTO CACHE blacklist_keycache; >> init-file.sql STEP 03) Add this to /etc/my.cnf [mysqld] init-file=/var/lib/mysql/init-file/sql STEP 04) Restart MySQL service mysql restart That's it. Going forward, every reload of the table will populate the dedicated key cache. Please note the `ROW_FORMAT=Fixed clause`. [**What that does is speed up character search 20-25% (I wrote about this before)**][5]. Why not use [**InnoDB**][6]? - The data and index pages would have the data twice in RAM. - Accessing an InnoDB table introduces additional mild disk I/O via data dictionary checking (See [**pictorial representation of ibdata1**][7]) - Index pages to rotate out is the InnoDB Buffer Pool is too small. Contrariwise, an [InnoDB Buffer Pool][8] too big wastes RAM. Using [MyISAM][9], the data remains on disk but is exclusively accessed from the dedicate key cache. [1]: http://dev.mysql.com/doc/refman/5.5/en/memory-storage-engine.html [2]: http://dev.mysql.com/doc/refman/5.5/en/memory-storage-engine.html [3]: http://dev.mysql.com/doc/refman/5.5/en/memory-storage-engine.html [4]: http://dba.stackexchange.com/tags/myisam/info [5]: http://dba.stackexchange.com/a/4589/877 [6]: http://dba.stackexchange.com/tags/innodb/info [7]: http://www.scribd.com/doc/31337494/XtraDB-InnoDB-internals-in-drawing [8]: http://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_buffer_pool_size [9]: http://dba.stackexchange.com/tags/myisam/info