MySQL innodb引擎中小心count(*)陷阱
以下的文章主要描述的是MySQL innodb引擎中的count(*)陷阱，你如果對MySQL innodb引擎中的count(*)陷阱有興趣的話你就可以點擊以下的文章進行觀看了。希望會給你帶來一些幫助在此方面。
word引起MySQL數(shù)據(jù)庫崩潰？
InnoDB delete from xxx速度暴慢原因
MySQL Storage Engine 小記
推薦圈子: JBPM @net
更多相關(guān)推薦 今天同學們在群里討論oracle的count(*)與count(1)的問題，正好提到MySQL的情況。我突然想到自己遇到的問題：在myisam引擎執(zhí)行count(*)速度非?？?，而且執(zhí)行速度與記錄條數(shù)無關(guān)，而MySQL innodb卻不是這樣，記錄越多，速度越慢。
于是做了一個實驗，在一個有8000W條記錄的innodb表執(zhí)行了一下 select count(*) from table 。 果然一直等待，大概8分多后出來結(jié)果。馬上再次執(zhí)行相同的語句，用時大約22秒。馬上執(zhí)行第三次，還是約22秒。
于是我猜想innodb沒有把記錄數(shù)保存起來，而是做了實時統(tǒng)計，所以導致速度比較慢。第二次、第三次相對較快是因為高速緩存的原因。于是打電話咨詢DBA同學。經(jīng)過DBA同學的專業(yè)解答，我明白了：我猜對了，呵呵。所以，以后要注意在MySQL innodb中count(*)的問題，盡量避免吧……除非能確保該表始終保持很少的記錄數(shù)。
另外，在網(wǎng)上查了一些資料：
引用
InnoDB Pitfalls
However, all is not rosy with InnoDB. Because of its transactional nature, it has bottlenecks of its own. On MyISAM, doing a query that does SELECT COUNT(*) FROM {some_table}, is very fast, since MyISAM keeps the information in the index.
On InnoDB, this info is not stored in an index, and even the index and the data are kept in the same file. So, doing the same query on a table can incur a significant performance penalty.
To check what overhead this has, I wrote a simple test benchmark code. I duplicated a client node table that has 20,243 rows from MyISAM to InnoDB.
On a quiescent AMD 64 machine with MySQL server 5.0.24, doing a SELECT COUNT(*) FROM node takes 0.835 milliseconds on MyISAM, while on InnoDB it takes 12.292 milliseconds!
以上就是對MySQL innodb引擎的count(*)問題的描述。
【編輯推薦】
