Cognos BI 的 MySQL 複製表
商業智能人員要求更快的機器、最新的軟體等，他的一些客戶抱怨查詢時間超過一個小時。該工具是 Cognos/Insight，數據庫是主 MySQL 的複制副本，我們很快將遷移到 MariaDB。
我的直覺（在我對 SQL 和執行計劃感到厭煩之前）是我們只是在處理來自 Cognos 的優化不佳的查詢以及不適當的索引集合來支持它們。
我的問題是（在我定制解決方案之前）：是否有可接受的實時從表策略允許主表上不存在的索引？
在從屬伺服器上啟用慢查詢日誌，
log_queries_not_using_indexes應該能夠確認你的直覺告訴你什麼。您可以獲取擷取的查詢，EXPLAIN對其進行執行，並更好地記錄您的懷疑。為了更直接地回答這個問題，在從屬設備上聲明未在主設備上聲明的索引是絕對有效的。我建議這是一種常見的做法，也是副本對這麼多事情有用的眾多原因之一。使用具有足夠權限的帳戶連接到從站，並直接在從站上更改表。
唯一的例外——這應該是直覺的，因為行數據需要在主伺服器和副本上保持一致——是
UNIQUE當從伺服器上不存在約束或外鍵約束時，你不能安全地聲明它。大師。這是行不通的，這很好，因為無論如何它沒有意義。另請記住，MySQL 中的索引具有名稱，如果在添加索引時未提供名稱，則會自動生成這些名稱。一個好的做法可能是在副本上顯式命名這些索引，以便將來添加到主伺服器的索引不可能導致索引名稱衝突，這會破壞複製。我的本地約定是在索引名稱前加上“ix_repl_”前綴，這當然不會在主伺服器上使用。
ALTER TABLE t1 ADD KEY ix_repl_last_first (last_name,first_name);另請注意，在 MySQL 5.6 中不推薦使用正確的重複索引（在多個索引中包含完全相同的列，並且不包含其他列），並且預設情況下在 MySQL 5.7 中是不允許的，這使得在以後的版本中顯然有可能導致複製停止如果您隨後在主伺服器上聲明了相同的索引（即使名稱不同）。這不會是一個關鍵問題（只要您正在監視複製——您是，對嗎？），因為在重新啟動從屬 SQL 執行緒之前，只需刪除副本上的現在冗餘索引即可安全地重新啟動複製。失敗的事件將被重試，並且現在是有效的，因為沒有衝突的索引，並且替換索引將建立在副本上。
旁注：請記住，MySQL 複製要求副本伺服器上的 MySQL 版本與主伺服器上的版本相同或更新……所以在升級（或遷移到 MariaDB）時，您幾乎肯定會想要升級首先是副本，然後是主伺服器。這樣做的原因是較新的副本將了解舊主伺服器的功能和怪癖，但較新的主伺服器可能會在複製流中引入舊副本伺服器無法解釋的行為。這條規則有有限的例外，但它絕對是規則。