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隐式转换问题

回答

相关问题