MySQLinnodb引擎中小心count(*)陷阱

以下的文章主要描述的是MySQL innodb引擎中的count(*)陷阱，你如果對MySQL innodb引擎中的count(*)陷阱有興趣的話你就可以點擊以下的文章進行觀看了。希望會給你帶來一些幫助在此方面。 word引起MySQL數據庫崩潰？ InnoDB delete from xxx速度暴慢原因 MySQL

以下的文章主要描述的是MySQL innodb引擎中的count(*)陷阱，你如果對MySQL innodb引擎中的count(*)陷阱有興趣的話你就可以點擊以下的文章進行觀看了。希望會給你帶來一些幫助在此方面。

word引起MySQL數據庫崩潰？

InnoDB delete from xxx速度暴慢原因

MySQL Storage Engine 小記

推薦圈子: JBPM @net

更多相關推薦 今天同學們在群里討論oracle的count(*)與count(1)的問題，正好提到MySQL的情況。我突然想到自己遇到的問題：在myisam引擎執行count(*)速度非常快，而且執行速度與記錄條數無關，而MySQL innodb卻不是這樣，記錄越多，速度越慢。

于是做了一個實驗，在一個有8000W條記錄的innodb表執行了一下 select count(*) from table 。 果然一直等待，大概8分多后出來結果。馬上再次執行相同的語句，用時大約22秒。馬上執行第三次，還是約22秒。

于是我猜想innodb沒有把記錄數保存起來，而是做了實時統計，所以導致速度比較慢。第二次、第三次相對較快是因為高速緩存的原因。于是打電話咨詢DBA同學。經過DBA同學的專業解答，我明白了：我猜對了，呵呵。所以，以后要注意在MySQL innodb中count(*)的問題，盡量避免吧……除非能確保該表始終保持很少的記錄數。

另外，在網上查了一些資料：

引用

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!

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com