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
您已使用 mariadb
和 mysql
标记您的问题。如果您使用的是最新版本的 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 索引快。
在您解决了您陈述的散列问题后,请报告查询是否比使用索引更快。即使与索引进行对比,我预测分区也不会 运行 更快,甚至可能 运行 慢一点。
是否可以在 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
您已使用 mariadb
和 mysql
标记您的问题。如果您使用的是最新版本的 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 索引快。
在您解决了您陈述的散列问题后,请报告查询是否比使用索引更快。即使与索引进行对比,我预测分区也不会 运行 更快,甚至可能 运行 慢一点。