› MySQL 5.5 Community Server
› MySQL 5.6 Community Server
› Percona Configuration Wizard
› XtraBackup 搭建主从复制
Great Sites on MySQL
› Percona
› MySQL Performance Blog
› Severalnines
推荐管理工具
› Sequel Pro
› phpMyAdmin
推荐书目
› MySQL Cookbook
MySQL 相关项目
› MariaDB
› Drizzle
参考文档
› http://mysql-python.sourceforge.net/MySQLdb.html
MySQL 相关项目
› MariaDB
› Drizzle
参考文档
› http://mysql-python.sourceforge.net/MySQLdb.html
这是一个创建于 472 天前的主题，其中的信息可能已经有所发展或是发生改变。
接手了一个奇葩要求的新项目，说已有数据库结构的，要在此基础上去重新开发跟扩展，发现了这么一个表，建了 3 个看起来一样的索引，虽然我很难理解，但鉴于我 mysql 的知识水平有限，所以慎重起见来此劳烦大家解惑一下这样做的意义是什么？是有我考虑外的特殊作用吗？
CREATE TABLE `abc` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`type` VARCHAR(100) NULL DEFAULT NULL COLLATE 'utf8mb4_general_ci',
`v0` VARCHAR(100) NULL DEFAULT NULL COLLATE 'utf8mb4_general_ci',
`v1` VARCHAR(100) NULL DEFAULT NULL COLLATE 'utf8mb4_general_ci',
`v2` VARCHAR(100) NULL DEFAULT NULL COLLATE 'utf8mb4_general_ci',
`v3` VARCHAR(100) NULL DEFAULT NULL COLLATE 'utf8mb4_general_ci',
`v4` VARCHAR(100) NULL DEFAULT NULL COLLATE 'utf8mb4_general_ci',
`v5` VARCHAR(100) NULL DEFAULT NULL COLLATE 'utf8mb4_general_ci',
PRIMARY KEY (`id`) USING BTREE,
UNIQUE INDEX `idx_a_abc` (`type`, `v0`, `v1`, `v2`, `v3`, `v4`, `v5`) USING BTREE,
UNIQUE INDEX `idx_b_abc` (`type`, `v0`, `v1`, `v2`, `v3`, `v4`, `v5`) USING BTREE,
UNIQUE INDEX `idx_c` (`type`, `v0`, `v1`, `v2`, `v3`, `v4`, `v5`) USING BTREE
)
COLLATE='utf8mb4_general_ci'
ENGINE=InnoDB
ROW_FORMAT=DYNAMIC
;
CREATE TABLE `abc` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`type` VARCHAR(100) NULL DEFAULT NULL COLLATE 'utf8mb4_general_ci',
`v0` VARCHAR(100) NULL DEFAULT NULL COLLATE 'utf8mb4_general_ci',
`v1` VARCHAR(100) NULL DEFAULT NULL COLLATE 'utf8mb4_general_ci',
`v2` VARCHAR(100) NULL DEFAULT NULL COLLATE 'utf8mb4_general_ci',
`v3` VARCHAR(100) NULL DEFAULT NULL COLLATE 'utf8mb4_general_ci',
`v4` VARCHAR(100) NULL DEFAULT NULL COLLATE 'utf8mb4_general_ci',
`v5` VARCHAR(100) NULL DEFAULT NULL COLLATE 'utf8mb4_general_ci',
PRIMARY KEY (`id`) USING BTREE,
UNIQUE INDEX `idx_a_abc` (`type`, `v0`, `v1`, `v2`, `v3`, `v4`, `v5`) USING BTREE,
UNIQUE INDEX `idx_b_abc` (`type`, `v0`, `v1`, `v2`, `v3`, `v4`, `v5`) USING BTREE,
UNIQUE INDEX `idx_c` (`type`, `v0`, `v1`, `v2`, `v3`, `v4`, `v5`) USING BTREE
)
COLLATE='utf8mb4_general_ci'
ENGINE=InnoDB
ROW_FORMAT=DYNAMIC
;
 |
1
sadfQED2 2023-08-14 09:08:35 +08:00 via Android
别瞎猜了，建表的时候手滑多按了几下而已
|
|
2
sadfQED2 2023-08-14 09:09:45 +08:00 via Android
最后那个顺序不一样是有用的，顺序完全一样就没啥意义了
|
 |
3
opengps 2023-08-14 09:10:38 +08:00
如果有特殊作用，哪似乎只剩下一个解释：就是分别给三个场景使用，每个场景里独立使用自己的强制索引，便于针对性调优
|
|
4
opengps 2023-08-14 09:13:04 +08:00
正常来讲，这种几乎全文级别的索引不应当被建立。所以不用花太多精力研究这部分了，很可能是卢浮宫里保洁忘带了的拖把，去观赏很浪费精力
|
 |
5
Vegetable 2023-08-14 09:13:12 +08:00  1
这波啊，是手动负优化，为性能优化预留空间。
|
 |
6
msaionyc 2023-08-14 09:46:41 +08:00
没有意义，直接删掉吧，平白无故浪费存储空间
|
 |
7
xiangyuecn 2023-08-14 10:01:06 +08:00 2
黑纸白字写着：屎山别动
|
 |
8
CEBBCAT 2023-08-14 10:20:03 +08:00
唔，某种分库分表？
|
 |
9
8355 2023-08-14 10:38:30 +08:00
这个写库速度会变慢吧。。。
|
 |
10
bugmakerxs 2023-08-14 11:16:37 +08:00
作用就是后续优化
|
 |
11
chendl111 2023-08-14 11:17:27 +08:00
说不定是不同的 sql 用了不同的索引？否则就是毫无意义，要是顺序不一样还可以解释一下
|
 |
12
luzemin 2023-08-14 13:40:18 +08:00
说明项目组曾今来过三个老弟，每人创建了一个
|
 |
13
IDAEngine 2023-08-14 15:39:14 +08:00
手抖了，轻松完成了代码 KPI
|
 |
14
winglight2016 2023-08-14 16:51:27 +08:00
@Vegetable #5 真相了，我们做过实验，同一个索引建立两次会导致查询变慢很多——跟没建索引一样，走全表扫描
|
Select Language