Mysql/mariadb innodb：行大小会影响复杂查询性能吗？答案

【问题标题】：Mysql/mariadb innodb: does row size affect complex query performance?Mysql/mariadb innodb：行大小会影响复杂查询性能吗？
【发布时间】：2016-03-04 00:59:33
【问题描述】：

我的 MariaDB 10 服务器上有数百万行（统计事件）的 InnoDB 表，并且每一行历史上都有一个长的 user-id char(44) 字段（用作非唯一键）以及其他 30 个 int/varchar 字段（行大小约为 240 字节）。我的系统可以进行同期群分析、漏斗、事件细分和其他常见的统计——所以一些查询非常复杂，有很多连接。现在我有机会添加 4 字节 int 字段并将其用作用户 ID 和所有查询的主要非唯一键。但由于实现细节，我需要在此表中保留旧的符号 char(44) 用户 ID - 一些数据源不是我的，仅使用符号用户 ID 发送事件。

所以问题是：一般来说，保留或删除这个 char(44) 字段会影响复杂查询的性能吗？它将像其他字符字段一样保持不变，并且不再用作查询中的键。我不想拆分表，因为有很多代码取决于它的结构。

谢谢！

测试了 Aria，发现它比 InnoDB 慢约 1.5 倍，即使是在简单的连接上也是如此。具有“冗余”行格式的 InnoDB 工作得更快。所以 - 不，Aria 不是妥协，它甚至比 myISAM 还要慢。我想 InnoDB 是 Maria10 中的 XtraDB，这解释了速度。

还对自连接查询进行了一些测试，发现如果我们不使用该字段，保留或删除 char(44) 字段对查询性能没有影响。

从 char(44) 键转移到 int 使查询速度提高了 2 倍！

【问题讨论】：

CHAR(44) utf8 总是占用 132 个字节！ INT 只需要 4 个。更大 --> 占用更多空间 --> 每个块的记录更少 --> 更多 I/O --> 更慢。
@RickJames 当我没有在查询中提取它时，它不会影响，但是是的，它的冗余字段。但是由于第三方逻辑，目前我无法摆脱它。顺便说一句，为什么它是 132 字节？它是 latin1_bin
在您的情况下始终为 44 个字节。（今天大多数人使用 utf8。）

标签： mysql performance innodb mariadb query-performance

【解决方案1】：

切换到较短的整数键将有助于提高查询性能。固定长度字符列的索引开销并不可怕。

正如您所提到的，在您的数据库服务器中填充更多 RAM 和/或一些 SSD 磁盘很可能比重构您的程序成本更低。

真正有助于提高查询性能的是创建适当的compound covering indexes。如果您的查询可以仅从这样的索引中得到满足，那么事情会变得更快。

例如，如果你做了很多

SELECT integer_user_id
  FROM table
 WHERE character_user_id = 'constant'

那么(character_user_id) 上的复合索引将使这个查询非常快。

添加大量索引时要小心：在具有许多索引的表中执行 INSERT 或 UPDATE 时要付出代价。

【讨论】：

感谢您的回答！当然我使用SSD，8核，32G RAM，针对不同查询有很多简单和复合索引，插入时间并不关键。但我问过 - 我可以将旧索引列留在表中吗？如果我不再在查询中使用它，将其保留在表中或从表中删除会影响性能吗？
你有很多硬件。无需删除旧的 44 个字符的列。将其留在原处。（如果是 128MiB TEXT 列，答案会有所不同！）如果您已停止使用该列进行查询，则可以将其从索引中删除。
谢谢！即使是这么大的设备有时也不会那么快——在分段漏斗和复杂的群组分析中的 100k+ 用户（免费应用程序）的数百万个事件——确实是需要几分钟才能执行和解析结果数据集的繁重查询。关于 44 字符列 - 我宁愿保留它，因为我将来会需要它，因为远程第三方系统使用符号 uid，我需要以后能够指向一些用户。
就其价值而言，PostgreSQL 具有卓越的统计分析/聚合功能，以及窗口操作。价格是一样的。
是的，我知道，但我在大约 8 年前使用过 postgre，几乎忘记了一切，而我在轻量级处理中经常使用 mysql。现在后悔用mysql开始这个项目，但是写了很多代码，当然现在也没有时间移植了