V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
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
way2create
V2EX  ›  MySQL

朋友们, mysql 中这样做的作用是什么?谢谢

  •  
  •   way2create · 2023-08-14 09:05:21 +08:00 · 3065 次点击
    这是一个创建于 466 天前的主题,其中的信息可能已经有所发展或是发生改变。
    接手了一个奇葩要求的新项目,说已有数据库结构的,要在此基础上去重新开发跟扩展,发现了这么一个表,建了 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
    ;
    14 条回复    2023-08-14 16:51:27 +08:00
    sadfQED2
        1
    sadfQED2  
       2023-08-14 09:08:35 +08:00 via Android
    别瞎猜了,建表的时候手滑多按了几下而已
    sadfQED2
        2
    sadfQED2  
       2023-08-14 09:09:45 +08:00 via Android
    最后那个顺序不一样是有用的,顺序完全一样就没啥意义了
    opengps
        3
    opengps  
       2023-08-14 09:10:38 +08:00
    如果有特殊作用,哪似乎只剩下一个解释:就是分别给三个场景使用,每个场景里独立使用自己的强制索引,便于针对性调优
    opengps
        4
    opengps  
       2023-08-14 09:13:04 +08:00
    正常来讲,这种几乎全文级别的索引不应当被建立。所以不用花太多精力研究这部分了,很可能是卢浮宫里保洁忘带了的拖把,去观赏很浪费精力
    Vegetable
        5
    Vegetable  
       2023-08-14 09:13:12 +08:00   ❤️ 1
    这波啊,是手动负优化,为性能优化预留空间。
    msaionyc
        6
    msaionyc  
       2023-08-14 09:46:41 +08:00
    没有意义,直接删掉吧,平白无故浪费存储空间
    xiangyuecn
        7
    xiangyuecn  
       2023-08-14 10:01:06 +08:00   ❤️ 2
    黑纸白字写着:屎山别动
    CEBBCAT
        8
    CEBBCAT  
       2023-08-14 10:20:03 +08:00
    唔,某种分库分表?
    8355
        9
    8355  
       2023-08-14 10:38:30 +08:00
    这个写库速度会变慢吧。。。
    bugmakerxs
        10
    bugmakerxs  
       2023-08-14 11:16:37 +08:00
    作用就是后续优化
    chendl111
        11
    chendl111  
       2023-08-14 11:17:27 +08:00
    说不定是不同的 sql 用了不同的索引?否则就是毫无意义,要是顺序不一样还可以解释一下
    luzemin
        12
    luzemin  
       2023-08-14 13:40:18 +08:00
    说明项目组曾今来过三个老弟,每人创建了一个
    IDAEngine
        13
    IDAEngine  
       2023-08-14 15:39:14 +08:00
    手抖了,轻松完成了代码 KPI
    winglight2016
        14
    winglight2016  
       2023-08-14 16:51:27 +08:00
    @Vegetable #5 真相了,我们做过实验,同一个索引建立两次会导致查询变慢很多——跟没建索引一样,走全表扫描
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   909 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 21:47 · PVG 05:47 · LAX 13:47 · JFK 16:47
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.