我有12列，一個主鍵和兩個獨特的密鑰的MySQL表。我在這個表中有或多或少的86000行/記錄。 我用這個MySQL代碼：爲什麼我的MySQL表有優化頻繁
INSERT INTO table (col2,col3,-------col12) VALUES ($val2,$val3,----------$val12) ON DUPLICATE KEY UPDATE col2=VALUES($val2), col3=VALUES($val3),----------------col12=VALUES($val12)
當我觀看來自的cPanel phpmyadmin的這個表的結構，看得出只是表中的索引信息下面「優化表」鏈接。如果我點擊鏈接，表格會進行優化。
但我的問題是爲什麼我看到'優化表'鏈接如此頻繁（在3/4天內，它出現）在這張表中，而這個數據庫的其他表不顯示優化錶鏈接（他們顯示每月一次甚至每兩個月甚至一次）。
，因爲我不刪除此表中的行，就插入，如果重複鍵發現，剛剛更新，那麼爲什麼需要優化如此頻繁？
答案很簡單：開關InnoDB的
MyISAM存儲引擎使用B樹索引的，並創建索引文件。每次插入大量數據時，這些索引都會更改，這就是爲什麼您需要優化表格以重新組織索引並重新獲得一些空間。
MyISAM數據的索引機制需要比Innodb的更多的空間。
鏈接還有很多其他優勢InnoDB的過度的MyISAM但那是另一個話題。
InnoDB也爲索引使用B樹。由於聚集索引，InnoDB的插入性能可能會變差。 –
是的，它使用B-樹，但它以不同的方式存儲它們。這一天不再是真的。如果您正確配置innodb，它會在每種情況下執行MyISAM。更不用提MVCC了，它可以防止鎖定並使備份更容易 –
http://vimeo.com/20990641摩根爲這裏的innodb提供了一個很好的例子 –
我將解釋如何插入記錄影響MyISAM表，並解釋所做的優化，所以你就會明白爲什麼插入記錄有這麼大的影響。
數據
於MyISAM，當你插入記錄，數據被簡單地附加到數據文件的末尾。
運行優化上MyISAM表碎片整理的數據，重新排序物理它以匹配主鍵索引的順序。這加快了順序記錄讀取（和表掃描）。
指標
插入記錄還增加了葉子在索引B樹的節點。如果一個節點填滿了，它必須被拆分，至少重建索引的那個頁面。
當優化MyISAM表，所述索引被變平，從而允許更多空間擴張（插入），其具有以重建索引頁之前。這個平坦的索引也加快了搜索速度。
統計
MySQL還爲每個索引有關密鑰分配，並查詢優化賣場的統計數據使用這些信息來幫助建立一個良好的執行計劃。插入（或刪除）許多記錄會導致這些統計信息過期。
優化MySQL重新計算碎片整理和重建索引之後的表的統計信息。
與追加
當您將數據追加（添加具有較高的主鍵值的記錄，如與AUTO_INCREMENT），該數據將不再需要在以後磁盤碎片整理，因爲它已經在適當的物理順序。另外，當追加（順序插入）到索引中時，節點保持平坦，因此在那裏不需要重建。
與InnoDB的
的InnoDB從插入時同樣的問題受到影響，但由於數據保存在按主鍵，由於其聚簇索引，你把撞了上去前（當時它插入）用於保持數據的有序性，而不是稍後進行碎片整理。儘管如此，優化InnoDB通過平滑B樹節點並釋放未使用的（已刪除的）密鑰來優化數據，這會改進順序讀取（表掃描），並且二級索引與MyISAM中的索引類似，因此它們將被重建爲平坦他們出去了。
結論
我沒有試圖讓堅持使用MyISAM數據的情況下。 InnoDB由於聚簇索引具有卓越的讀取性能，並且由於記錄級別鎖定與MyISAM的表鎖定（假設併發用戶）相比具有更好的更新和追加性能。另外，InnoDB有ACID。
不過，我的目標是回答你的直接問題，並提供一些技術細節，而不是猜測和傳聞。
兩個數據庫存儲引擎都不會自動優化自己。
感謝您的詳細解答+1 –
你有innodb_file_per_table啓用嗎？ –
您是否更新唯一密鑰中的列？ –
不，它不是innodb結構化表，它的引擎是MyISAM – stockBoi