MySQL 基于 INT 列最后一位的索引

MySQL index based on last digit of INT column

是否可以在 MySQL 中为 int 列的最后一位创建索引?

基于此answer 我已经根据 int 列的最后一位数字创建了分区

CREATE TABLE partition_test(
  textfiled INT,
  cltext TEXT,
  reindexedAt TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
  indexedAt TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
  status TINYINT(2),
  postId INT)
PARTITION BY HASH(MOD(postId, 10))
PARTITIONS 10;

我正在尝试为 postId 的最后一位创建索引以优化查询时间。有什么办法可以做到这一点,或者 postId 上的简单索引就足够了吗?

一些失败的尝试:

CREATE INDEX postLastDigit USING HASH ON partition_test (MOD(postId, 10));
(1064, u"You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'MOD(postId, 10))' at line 1")

CREATE INDEX postLastDigit ON partition_test (MOD(postId, 10));
(1064, u"You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'MOD(postId, 10))' at line 1")

更新: table 的行数超过 100M。

我的目标是优化如下查询:

1)

SELECT cltext FROM partition_tables 
  WHERE postId in (<INT>, <INT>) 
  AND status IS NOT NULL

2)

SELECT cltext FROM partition_tables 
  WHERE postId in (<INT>, <INT>) 
  AND status IS NOT NULL
  AND reindexedAt BETWEEN (<DATE>, <DATE>)

MariaDB 版本:10.1.23-MariaDB-9+deb9u1

您已使用 mariadbmysql 标记您的问题。如果您使用的是最新版本的 MariaDB,则可以使用生成的列进行索引。如果您正在使用 MySQL,并且您的 MySQL 版本至少为 5.7。

如果您使用的是较低版本的 MySQL,您可以在 table 中创建一个额外的列,用于存储每行 postId 的最后一位数字,然后使用用于索引/分区的列。

这意味着对您的应用程序代码的更改最少:在插入或更新之前,先获取 postId 的最后一位,然后再插入/更新一个字段。作为替代方案,您最终可以使用触发器自动填充该附加列。

使用虚拟列。在 MariaDB 10.2 中,您可以在 virtual aka generated column 上创建索引,像这样

 CREATE TABLE t (
  num int,
  last_digit int(1) AS (num % 10) VIRTUAL,
  KEY index_last_digit (last_digit)
)

然后您可以在查询中使用 last_digit,即 SELECT ... WHERE last_digit=1

在旧版本的 MariaDB 5.2 到 10.1 中,您需要指定 PERSISTENT 属性而不是 VIRTUAL,因为无法为非持久生成的列编制索引。

您要加快什么查询? table 上没有任何索引,任何 查询都必须扫描整个 table!如果你想要速度,首先要看索引。

如果您的查询是 SELECT ... WHERE post_id = 123,您的分区可能会使它 运行 快大约 10 倍。但是 INDEX(post_id),有或没有分区,都会使它 运行 快数百倍。

请提供 SELECTs 以便我们帮助您加快速度。

(好吧,如果你只是在玩分区,其他人已经给了你可行的答案。)

"Partition Pruning" 很少比以 p运行ing 列开头的 suitable 索引快。

在您解决了您陈述的散列问题后,请报告查询是否比使用索引更快。即使与索引进行对比,我预测分区也不会 运行 更快,甚至可能 运行 慢一点。