期望支持CRC32函数表达式或字符串字段的HASH分区

🌞 建议反馈 产品需求
1

需求反馈

【需求涉及的问题场景】

MySQL迁移兼容性问题：
原业务系统使用MySQL通过Sharding-JDBC分表，且分表逻辑为UUID类型字符串字段HASH取模。当前希望迁移到TiDB，然而试图采用PARTITION BY HASH(CRC32(store_id)) 对字符串字段 store_id 分区，但TiDB的HASH分区仅支持整型字段，且分区表达式函数列表不包含 CRC32()。

【期望的需求行为】

  1. 扩展分区表达式支持：
    • 允许在分区表达式中使用 CRC32() 函数，实现字符串到整型的转换（如 PARTITION BY HASH(CRC32(store_id))）。
    • 或 更优方案：使HASH分区直接支持字符串字段，由TiDB内部自动处理哈希计算（如 PARTITION BY HASH(store_id)）。

【需求可替代方案】

方案 缺点
沿用Sharding-JDBC分表 失去TiDB内置分区优化（如分区裁剪、自动数据分布），需维护中间件，增加运维复杂度。
新增整型冗余字段 需改造业务逻辑：
- 所有写入操作需预计算CRC32(store_id)并存为额外字段；
- 所有查询需显式携带哈希值，代码侵入性强。

【背景信息】

  • 受益用户：
    • 从MySQL迁移至TiDB且依赖CRC32()分区的业务（如电商、IoT场景）。
    • 使用字符串主键（如UUID）分库分表的系统，需最小化迁移成本。
  • 关键场景：
    • 分片逻辑迁移：原分表键为UUID类型的store_id（如店铺ID），需在TiDB保持相同数据分布策略。
    • 查询性能优化：避免全表扫描，利用分区裁剪加速WHERE store_id=xxx类查询。
2

虽然没有是一个Sharding-JDBC分表。。但相信不止楼主一人有这样的需求。。。希望官方考虑一下。感谢了。

3

又想分布式数据库，又想支持分库分表，不是不可以，这个成本…

4

希望支持字符串HASH分区，就不用自己考虑分库分表了，直接享受分布式数据库的好处。我们几十个库和微服务，上千张表的平台要迁移。以前受限于MySQL单表数量性能瓶颈做的分表。现在用了分布式数据库再分表是很蠢啦。

5

primary_partition int(4) GENERATED ALWAYS AS ((crc32(patent_id)) % 9999) STORED NOT NULL, 以前tidb不支持分区表的时候，我们用的这种方式做的伪分区

6

这种方式如果where语句查询patent_id字段，应该是无法带来分区裁剪的查询性能提升的吧，但是不是可以带来高并发写入的性能提升？如果仅带来写入性能提升倒是也可以接受，查询性能也不会更差吧。

7

并不是物理意义上的分区，不会有分区裁剪的。我们那时用tidb时，还不支持分区，只好用这种办法。而且我们也不是为了查询性能。

8

wow～ 这样也行，， :sunny: