MySQL5.6 vs Percona 5.7隱式轉換問題

我們最近開始測試從mySQL5.6升級到percona服務器5.7和使用tokuDB表。該數據庫服務於我們的PHP 5.5應用程序，它使用PDO庫進行參數化查詢。MySQL5.6 vs Percona 5.7隱式轉換問題

將相同數據的percona加載到tokudb表中，並將性能與現有生產進行比較，我們立即注意到性能的巨大下降（速度降低了10倍）。對於下面的查詢假設表有1200萬行

我已經能夠在5.7數據庫向下縮小這個問題的事實，執行查詢，例如當：

SELECT * FROM TABLE WHERE id='12345'; -- exec time 10.5sec 
vs. 
SELECT * FROM TABLE WHERE id=12345; -- exec time 1.3sec

其中id是列類型的整數。這是我的印象，我的研究似乎證實，當比較列是一個數字類型時，mySQL應該將'12345'隱式轉換爲12345，但是這似乎不會在mySQL5.7/Percona中發生。這是發生在mySQL5.6x

這裏的問題是，這種行爲，你需要明確地設置每個變量使用PDOStatement :: bindParam（ref http://php.net/manual/en/pdostatement.bindparam.php）的類型！這樣做會導致所有準備好的語句接近全局重寫，這些語句當前將參數數組傳遞給PDOStatement：execute（），它不支持顯式類型設置！

所以 - 我的問題是這樣的 - 在mySQL中有一些變化，所以隱式轉換不是在5.7中完成，或者是Percona還是tokuDB表？有一個配置參數可以讓我們重新打開它嗎？

來源

2016-03-27 Ross

我會爲答案提出一個獎勵。 –

出於好奇，爲什麼遷移到Percona而不是更常見的MariaDB步驟？ – Jacco

@Jacco - 因爲Percona收購了tokutek。此外，Percona多年來一直是高性能mySQL領域的佼佼者。 – Ross

您不清楚您是否嘗試升級並比較5.6 TokuDB性能與5.7 TokuDB性能或5.6 InnoDB與5.7 TokuDB，請您澄清並確定具體5.6和5.7變體和版本？

如果TokuDB到處都是，則由於bad/old/NULL索引統計信息，一種可能性是不正確的索引選擇。在5.7中還有很多SQL_MODE默認值更改，其中一些也可能會影響行爲。

在5.6和5.7實例上查看'SHOW CREATE TABLE'和'SHOW INDEXES FROM'的結果也可能很有用。

來源

2016-03-28 15:47:13

儘管這些差異不幸是潛在的混雜因素，我的問題是真的是關於是否有問題（看起來好像）在mySQL或Percona中使用隱式類型轉換，可能在使用TokuDB引擎和InnoDB時使用。我強調的問題存在於使用Tokudb的Percona 5.7中，但不存在於使用InnoDB的Percona 5.6（或mySQL 5.6）中。 – Ross

據我所知，沒有已知的問題。類型轉換不是存儲引擎功能，上面的服務器在通過SE API將字段發送到引擎之前處理這些功能，所以必須有其他一些影響因素。充分披露，我是Percona的TokuDB技術主管。 –

MySQL5.6 vs Percona 5.7隱式轉換問題

回答

相關問題