我們有一個MySQL表，它有超過7.000.000（是七百萬）行。 我們總是每5秒做很多次SELECT/INSERT/UPDATE查詢。mysql速度，表索引和選擇/更新/插入
如果我們爲該表創建MySQL INDEX是否是件好事？會不會有一些不好的後果，比如數據破壞或丟失MySQL服務等？
一點信息：
的索引將有助於選擇。特別是如果匹配通常過濾的領域。而且你有一個很好的簡單主鍵。他們將幫助查詢和處理週期。
缺點是，如果你是很經常更新/更改/刪除這些記錄，特別是索引字段。即使在這種情況下，它通常也是值得的。
你要報告多少（選擇語句）與更新（應該！）極大地影響了你的初始設計以及隨後的調整，一旦你的數據庫處於瘋狂狀態。既然你已經有了你所擁有的東西，測試會給你你需要的答案。如果你真的做了很多選擇查詢和大量更新，你的解決方案可能是現在將數據拷貝到報告表。那麼你可以像瘋了一樣索引，沒有不良影響。
你實際上已經提出了一個很大的問題，你應該研究更多。上面提到的一般情況適用於大多數所有關係數據庫，但是也有特定數據庫的特定行爲（您的情況爲MySQL），主要表現在他們如何決定何時何地使用索引。
這隻適用於'SELECT'語句。在不知道讀寫操作之間的平衡的情況下，您無法知道添加索引是否會有所幫助或受傷。如果負載主要是插入，它可能會使事情變得更糟。 – cdeszaq 2012-01-11 15:04:15
通常，索引會提高SELECT操作的速度，並會減慢INSERT/UPDATE/DELETE操作，因爲在發生更改時基表和索引都必須修改。
匿名downvoter會照顧解釋他們的反對嗎？我在這裏說了些不對嗎？ – 2012-01-11 15:13:57
說這樣的事情是非常困難的。我預計索引本身可能需要一些時間。但之後，你應該有一些改進。正如@Joe和@Patrick所說，這可能會損害您的修改時間，但選擇會更快。
當然，還有一些方法可以提高插入和更新的性能。如果立即顯示更改並不重要，則可以批量更新批次。
如果您正在尋找性能，索引是要走的路。索引加速您的查詢。如果您有700萬條記錄，根據您的內存大小，您的查詢可能需要幾分鐘。
一般來說，我會創建匹配最頻繁的SELECT語句的索引。每個人都在談論索引對桌面大小和速度的負面影響，但是我會忽略這些影響，除非你有一張桌面，你在做95％的時間插入和更新，但即使如此，如果這些插入發生在晚上，而你查詢在白天，去創建這些索引，你的用戶在白天將欣賞它。 如果有一個額外的索引，那麼對插入或更新語句的實際時間影響是多少？如果索引爲每個查詢節省了很多秒，那麼我認爲更新索引所需的額外時間非常值得。
我唯一一次創建索引時遇到了問題（它實際上破壞了程序邏輯）是當我們將一個主鍵添加到之前由其他人創建的表中而沒有主鍵和程序期待SELECT語句按照它們創建的順序返回記錄。創建主鍵改變了這一點，沒有任何WHERE子句時選擇的記錄以不同的順序返回。 這顯然是一個錯誤的設計，然而，如果你有一個較舊的程序，並且你遇到沒有主鍵的表，我建議在添加一個主鍵之前查看讀取該表的代碼，以防萬一。
對於創建索引還有一個想法，字段的選擇和字段在索引中出現的順序會影響索引的性能。
我與您描述的問題具有相同種類。
我的確從11sec傳遞給升級到MariaDB的10.1
2-幾毫秒
1-一些變化和1個查詢改變了所有我的數據庫，以ARIA發動機
3-改變了我.CNF以嚴格的最小值
4-升級PHP 7.1（但是這一個有一個小的衝擊）
-5-在CentOS：「蔭更新」，在終端或通過ssh（通過保持所有最新）
1- MariaDB的是MYSQL的新開源版本
2- ARIA發動機是MYISAM的演變
3-我.CNF具有影響性能的通常太多變化 下面的例子
[mysqld]
performance-schema=1
general_log=0
slow_query_log=0
max_allowed_packet=268435456
通過從my.cnf文件刪除所有額外的選項，它告訴MySQL使用 默認值。
在MYSQL 5（5.1,5.5,5.6 ...）當我這樣做;我只注意到一個小小的差異。
但在MariaDB中 - >像這樣的小my.cnf做了很大的差異。
*******所有這些變化;服務器硬件保持不變。
希望它可以幫助你
我會咬，問顯而易見的：怎麼能* *任何使用CPU的100％以上？ – 2012-01-11 15:05:19
@PeteWilson - 這可能是每個CPU內核的負載總和。至於原來的問題 - 不要使用MyISAM，交換到InnoDB，是的，使用索引。至於什麼索引 - 沒有人可以告訴你，你提供的信息。 – 2012-01-11 15:13:00