Comments on: Performance gotcha of MySQL memory tables http://www.mysqlperformanceblog.com/2008/02/01/performance-gotcha-of-mysql-memory-tables/ Everything about MySQL Performance Sun, 21 Mar 2010 15:03:31 +0000 hourly 1 By: peter http://www.mysqlperformanceblog.com/2008/02/01/performance-gotcha-of-mysql-memory-tables/comment-page-1/#comment-483659 peter Fri, 20 Feb 2009 23:07:15 +0000 http://www.mysqlperformanceblog.com/2008/02/01/performance-gotcha-of-mysql-memory-tables/#comment-483659 Coway, There is nothing as generally representative case. In this case I was to show the particular behavior of HASH indexes with a lot of rows matching the same value. In other cases it depends differently of course. Note in this case it is not the search which is the problem but delete which is very expensive... Coway,

There is nothing as generally representative case. In this case I was to show the particular behavior of HASH indexes with a lot of rows matching the same value. In other cases it depends differently of course.

Note in this case it is not the search which is the problem but delete which is very expensive…

]]> By: Coway http://www.mysqlperformanceblog.com/2008/02/01/performance-gotcha-of-mysql-memory-tables/comment-page-1/#comment-482611 Coway Thu, 19 Feb 2009 19:59:17 +0000 http://www.mysqlperformanceblog.com/2008/02/01/performance-gotcha-of-mysql-memory-tables/#comment-482611 Peter, There is one problem in your test: the data is not representative. The cardinality for column 'c' is 1. Thus, there are too many duplicates for the same hash value. Under this situation, B-tree is much better than hash. If you randomly generate values for c, and increase the selectivity for column 'c', for the search with equal condition, hash should have better performance. Peter,

There is one problem in your test: the data is not representative. The cardinality for column ‘c’ is 1. Thus, there are too many duplicates for the same hash value. Under this situation, B-tree is much better than hash.

If you randomly generate values for c, and increase the selectivity for column ‘c’, for the search with equal condition, hash should have better performance.

]]> By: dbnewz » Blog Archive » Choisir l’implémentation de ses index : “B-TREE” ou “HASH”, quelles différences ? http://www.mysqlperformanceblog.com/2008/02/01/performance-gotcha-of-mysql-memory-tables/comment-page-1/#comment-300791 dbnewz » Blog Archive » Choisir l’implémentation de ses index : “B-TREE” ou “HASH”, quelles différences ? Sun, 18 May 2008 23:12:21 +0000 http://www.mysqlperformanceblog.com/2008/02/01/performance-gotcha-of-mysql-memory-tables/#comment-300791 [...] proportionnels à cette redondance sont à prévoir lors des UPDATE et DELETE. Un billet de Peter Zaitsev relate parfaitement ce [...] [...] proportionnels à cette redondance sont à prévoir lors des UPDATE et DELETE. Un billet de Peter Zaitsev relate parfaitement ce [...]

]]> By: Propiedad Privada » Blog Archive » Miscelánea de enlaces sobre Bases de datos http://www.mysqlperformanceblog.com/2008/02/01/performance-gotcha-of-mysql-memory-tables/comment-page-1/#comment-247241 Propiedad Privada » Blog Archive » Miscelánea de enlaces sobre Bases de datos Fri, 29 Feb 2008 15:44:19 +0000 http://www.mysqlperformanceblog.com/2008/02/01/performance-gotcha-of-mysql-memory-tables/#comment-247241 [...] Ojo con el tipo de índices que defines en las tablas Memory, en algunas circunstancias un índice BTREE puede ser hasta un 20000% más rápido, ahi es nada. Más información y test en Performance gotcha of MySQL memory tables [...] [...] Ojo con el tipo de índices que defines en las tablas Memory, en algunas circunstancias un índice BTREE puede ser hasta un 20000% más rápido, ahi es nada. Más información y test en Performance gotcha of MySQL memory tables [...]

]]>