MySQL innodb引擎中小心count(*)陷阱
以下的文章主要描述的是MySQL innodb引擎中的count(*)陷阱，你如果對(duì)MySQL innodb引擎中的count(*)陷阱有興趣的話你就可以點(diǎn)擊以下的文章進(jìn)行觀看了。希望會(huì)給你帶來(lái)一些幫助在此方面。
word引起MySQL數(shù)據(jù)庫(kù)崩潰？
InnoDB delete from xxx速度暴慢原因
MySQL Storage Engine 小記
推薦圈子: JBPM @net
更多相關(guān)推薦 今天同學(xué)們?cè)谌豪镉懻搊racle的count(*)與count(1)的問(wèn)題，正好提到MySQL的情況。我突然想到自己遇到的問(wèn)題：在myisam引擎執(zhí)行count(*)速度非常快，而且執(zhí)行速度與記錄條數(shù)無(wú)關(guān)，而MySQL innodb卻不是這樣，記錄越多，速度越慢。
于是做了一個(gè)實(shí)驗(yàn)，在一個(gè)有8000W條記錄的innodb表執(zhí)行了一下 select count(*) from table 。 果然一直等待，大概8分多后出來(lái)結(jié)果。馬上再次執(zhí)行相同的語(yǔ)句，用時(shí)大約22秒。馬上執(zhí)行第三次，還是約22秒。
于是我猜想innodb沒(méi)有把記錄數(shù)保存起來(lái)，而是做了實(shí)時(shí)統(tǒng)計(jì)，所以導(dǎo)致速度比較慢。第二次、第三次相對(duì)較快是因?yàn)楦咚倬彺娴脑?。于是打電話咨?xún)DBA同學(xué)。經(jīng)過(guò)DBA同學(xué)的專(zhuān)業(yè)解答，我明白了：我猜對(duì)了，呵呵。所以，以后要注意在MySQL innodb中count(*)的問(wèn)題，盡量避免吧……除非能確保該表始終保持很少的記錄數(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!
以上就是對(duì)MySQL innodb引擎的count(*)問(wèn)題的描述。
【編輯推薦】
