MySQL5.6 vs Percona 5.7 隐式转换问题答案

【问题标题】：MySQL5.6 vs Percona 5.7 implicit conversion issueMySQL5.6 vs Percona 5.7 隐式转换问题
【发布时间】：2016-07-15 00:48:48
【问题描述】：

我们最近开始测试从 mySQL5.6 升级到 percona server 5.7 以及 tokuDB 表的使用。该数据库为我们的 PHP 5.5 应用程序提供服务，该应用程序使用 PDO 库进行参数化查询。

将具有相同数据的 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 表？我可以设置一个配置参数来重新启用它吗？

【问题讨论】：

我会为答案悬赏。
出于好奇，为什么要迁移到 Percona 而不是更常见的 MariaDB 步骤？
@Jacco - 因为 Percona 收购了 tokutek。此外，percona 多年来一直是高性能 mySQL 领域的领军人物。
我会在空闲时间发布更多信息 - 加载具有不同服务器版本/表类型等的多个其他测试环境非常耗时

标签： php mysql pdo percona tokudb

【解决方案1】：

不清楚您是否尝试升级并比较 5.6 TokuDB 性能与 5.7 TokuDB 性能或 5.6 InnoDB 与 5.7 TokuDB 性能，能否请您澄清并确定具体的 5.6 和 5.7 变体和版本？

如果 TokuDB 到处都是，一种可能性是由于错误/旧/NULL 索引统计信息导致的错误索引选择。 5.7 中还有许多 SQL_MODE 默认值更改，其中一些也可能会影响行为。

在 5.6 和 5.7 实例上查看“SHOW CREATE TABLE”和“SHOW INDEXES FROM”的结果也可能很有用。

【讨论】：

虽然不幸的是这些差异是潜在的混淆因素，但我的问题实际上是关于 mySQL 或 Percona 中的隐式类型转换是否存在问题（似乎存在），可能是在使用 TokuDB 引擎与创新数据库。我强调的问题存在于带有 Tokudb 的 Percona 5.7 中，但不存在于带有 InnoDB 的 Percona 5.6（或 mySQL 5.6）中。
据我所知，没有已知问题。类型转换不是存储引擎的功能，上面的服务器在通过 SE API 将字段发送到引擎之前处理它，因此必须有其他一些影响因素。全面披露，我是 Percona 的 TokuDB 技术主管。