MariaDB ColumnStore中基于主键的Delete/Update操作异常缓慢问题排查

首先，结合你描述的现象——在MariaDB ColumnStore 1.2.5上的InnoDB表执行包含完整主键列的DELETE/UPDATE时，主键索引未被利用，导致全表扫描（扫描行数超50%），而相同表在普通MariaDB上执行相同SQL仅需10ms以内——核心问题应该出在ColumnStore环境对InnoDB复合主键的查询优化逻辑上，以下是具体分析和解决办法：

可能的原因 #

• ColumnStore版本特定bug：你使用的ColumnStore 1.2.5是比较早期的版本（发布于2020年前后），该版本在InnoDB表的复合主键索引识别、查询优化器逻辑上存在已知的兼容性问题，无法正确识别包含所有主键列的WHERE条件应该走主键查找。
• 复合主键的条件顺序影响：你的主键是(src_id, id)，而WHERE条件先写了id=...再写src_id=...，虽然逻辑上包含所有主键列，但ColumnStore的优化器可能对条件顺序更敏感，不像标准InnoDB能自动调整匹配主键顺序。
• ColumnStore的存储架构特性：ColumnStore本质是列存储引擎，即便你创建的是InnoDB表，其底层的查询执行、索引利用逻辑和标准MariaDB的InnoDB有差异，优化器优先级不同。

解决办法 #

1. 调整WHERE条件的列顺序 #

把条件改为先匹配复合主键的前导列，也就是把src_id放在前面：

DELETE FROM interest WHERE `src_id`='1' AND `id`='52f35ddb-94d0-4744-bb3c-f3ae8100dc8e';
UPDATE interest SET interest = 1 WHERE `src_id`='1' AND `id`='52f35ddb-94d0-4744-bb3c-f3ae8100dc8e';

ColumnStore的优化器更容易识别这种和主键顺序一致的条件，从而触发主键索引查找。

2. 强制指定使用主键索引 #

直接通过FORCE INDEX命令强制优化器使用主键索引，绕过优化器的错误判断：

DELETE FROM interest FORCE INDEX (PRIMARY) WHERE `id`='52f35ddb-94d0-4744-bb3c-f3ae8100dc8e' AND `src_id`='1';
UPDATE interest FORCE INDEX (PRIMARY) SET interest = 1 WHERE `id`='52f35ddb-94d0-4744-bb3c-f3ae8100dc8e' AND `src_id`='1';

3. 重新构建主键索引 #

如果索引存在统计信息不准确或隐性损坏的情况，重建主键可以解决：

ALTER TABLE interest DROP PRIMARY KEY, ADD PRIMARY KEY (`src_id`, `id`);

执行前建议先备份表数据，避免意外。

4. 升级MariaDB ColumnStore版本 #

1.2.5版本的ColumnStore在InnoDB兼容上有较多缺陷，升级到较新的稳定版本（比如当前的1.5.x或更高）可以从根源上修复这类优化器bug，同时获得更好的性能和兼容性。

5. 检查InnoDB相关配置 #

确认ColumnStore环境下的InnoDB参数设置合理，比如：

• innodb_buffer_pool_size：设置为服务器内存的50%-70%，确保索引能被高效缓存
• innodb_stats_on_metadata：确保统计信息自动更新，帮助优化器生成正确的执行计划

执行完上述操作后，可以再次用EXPLAIN EXTENDED查看执行计划，确认是否已经使用主键索引（type列显示const或eq_ref即表示主键查找生效）。

内容的提问来源于stack exchange，提问作者gshock