Logo Logo Logo
浅色
深色
跟随系统

博客 (5)

再记 Discuz! 论坛升级（阿里云、Discuz! X3.5）

本文记录于 2024 年 11 月。



升级前期望（最新正式版）最终选择
操作系统Alibaba Cloud Linux 3Alibaba Cloud Linux 3Alibaba Cloud Linux 3
管理面板宝塔面板 Linux 版 9.2.0宝塔面板 Linux 版 9.2.0宝塔面板 Linux 版 9.2.0
Web 服务nginx 1.24nginx 1.24nginx 1.24
脚本语言PHP 7.4PHP 8.2PHP 8.2
数据库
PolarDB MySQL 5.6RDS MySQL 9.1PolarDB MySQL 8.0
论坛程序
Discuz! X3.4 GBKDiscuz! X5.0Discuz! X3.5 UTF8


版本选择原因：

  • Discuz! X5 刚刚发布，生态尚未成熟，考虑到是老论坛升级，所以选择 X3.5。

  • Discuz! X3.5 目前最高支持 PHP 8.2、MySQL 8.0。


完整升级步骤：

  1. 购买新的 ECS、PolarDB，具体环境配置步骤参此文；

  2. 安装宝塔面板并配置；

  3. 安装 nginx 及 PHP；

  4. 创建网站、配置 SSL、伪静态、防盗链、可写目录禁执行、仅允许部分入口文件执行等（.conf）；

  5. 配置 hosts；

  6. 如果是正式升级阶段，关闭论坛，防止产生新数据。

  7. 备份原网站程序、PolarDB 数据库；

  8. PolarDB 创建快照。

    测试阶段：从快照还原到新实例（MySQL 5.6 不能直接恢复到 MySQL 8.0），然后从 5.6 迁移到 8.0.x；

    正式阶段：全量模式直接从原实例迁移到 8.0.x，若增量模式且存在触发器，建议从快照还原；

  9. 上传原网站程序到新的站点目录下；

  10. 按 Discuz! X 升级文档升级 X3.4 至 X3.5；详情见下文 ↓；

  11. 升级完成后切换到 PHP 8；

  12. 配置 OSS、Redis、更新缓存等；

  13. 测试论坛基本功能是否正常；检查附件是否能够正常上传；检查附件是否正常显示；全面检查控制台配置；

  14. 逐个开启插件并检查兼容性（短信通、马甲引擎等）；

  15. 按二开备忘录逐个按需进行二开；

  16. 逐个修改调用论坛接口的项目及直接调用论坛数据库的项目；

  17. 调试 MAGAPP 接口；

  18. 尝试强制 https 访问；

  19. 将以上所有修改后的程序保留备份；发布升级公告并关闭论坛；重复以上步骤；修改域名解析；开启论坛；

  20. 配置 IP 封禁、定时器、日志、自动备份、配置其它 ECS 的 hosts 等；

  21. 查看搜索引擎中收录的地址，是否有无法访问的情况；

  22. 尝试将历史遗留的本地附件全部转移到 OSS；

  23. 建议 在新服上创建 3 个网站：

    1. 第 1 个用来尝试迁移、升级、二开，并测试所有功能；

    2. 第 2 个用来再次重复这些步骤，最终保留程序代码及 UGC 文件，作为最终的网站程序，以正式域名作为网站根目录路径；

    3. 第 3 个用来正式升级，主要功能是升级最新数据库。完成后修改第 2 个网站的数据库连接指向到最新的数据库，差异化同步新增的 UGC 文件到第 2 个网站。


Discuz! X 升级步骤及注意点：

  • 因 PolarDB MySQL 不支持压缩，所以应移除 Discuz! 和 UCenter 代码中所有的 MYSQLI_CLIENT_COMPRESS，将 , MYSQLI_CLIENT_COMPRESS 替换为 /*, MYSQLI_CLIENT_COMPRESS*/。

  • 升级前务必先修改 ./config/ 目录下的数据库/缓存连接信息，以防出现新站连接老库的情况；

  • 按官方文档进行升级，升级前先修改一下：

  • 【UC】先升级 UCenter 1.6 至 1.7。

    将 /uc_server/data 权限改为 777 并递归。

    打开 update_ucenter_adult.php 修改 $limit 值为 10000 以免执行超时。

    因通信失败的“发送通知失败”可以直接改 URL 参数跳过就完成了，原因可能是因数据量大，发送改名通知执行改名时超时。等DZ升级完成后UC会自动重试改名通知，或单独写个 php 文件将 UCenter 的用户名同步到应用的数据库。

  • 【DZ】运行到 /install/update_adult.php?step=innodb&table=pre_common_member_grouppm 时报错：Duplicate key name 'gpmid' ALTER TABLE common_member_grouppm ADD INDEX gpmid(gpmid);

    解决方法：先删除索引，因保存时提示失败，应同时取消 gpmid 字段的自增，转换成功后再设置自增。

  • 【DZ】运行到 /install/update_adult.php?step=file 一片空白而停止

    正在解决

  • 【问题】common_menber 表用户名字段编码转换失败

    原因是部分用户名包含特殊字符（如全角空格），用以下语句查看两个表同一 uid 的不同用户：

    SELECT 
    u.uid, 
    u.username AS ucenter_username, 
    c.username AS common_username
FROM 
    pre_ucenter_members u
JOIN 
    pre_common_member c ON u.uid = c.uid
WHERE 
    u.username <> c.username

    Discuz! 用户登录都是以 UCenter 中的用户名为主，所以可以写个小程序直接将 pre_ucenter_members 的用户名同步到 pre_common_member 中，另外 pre_ucenter_members 的用户数少于 pre_common_member 是正常的。若 pre_common_member_archive 表遇到错误同理。

  • 如果用户登录慢，或打开 UCenter 慢，是因为 UC 正在通知 DZ 改用户名，每次打开一个页面会更改一个用户名，具体可以查看 pre_ucenter_notelist 中 closed 为 0 的队列，或进入 UC 后台-数据列表-通知列表 查看。

  • 【问题】发布主题遇到错误：(1062) Duplicate entry '*' for key 'pid'

    【原因】forum_post 中的 pid 不是自动增长的，而是由表 forum_post_tableid 中自动增长的 pid 生成的。如果生成的 pid 值已在 forum_post 表中存在，则会出现此错误。

  • 【解决】迁移数据库时应关闭论坛，以防止 forum_post 表有新数据插入。

  • 【问题】打开帖子页面 ./thread-***-1-1.html 显示 404 Not Found，而 ./forum.php?mod=viewthread&tid=*** 可以正常打开

    【原因】未配置伪静态（可在宝塔面板中选择）

  • 【问题】打开 UCenter 时报错：UCenter info: MySQL Query Error SQL:SELECT value FROM [Table]vars WHERE name='noteexists'

    【解决】打开文件 ./uc_server/data/config.inc.php 配置数据库连接

  • 【问题】打开登录 UCenter 后一片空白

    【解决】将目录 ./uc_server/data/ 设为可写

  • 需要将原来安装的插件文件移回 ./source/plugin/ 目录，并设置可写；

  • 界面-表情管理，界面-编辑器设置-Discuz!代码


后续 Discuz! X3.5 小版本升级注意事项：

  1. 确认插件是否支持新版本（如短信通）

  2. 先创建一个新网站测试二开代码

  3. 保留 /config/、/data/、/uc_client/data/、/uc_server/data/、/source/plugin/，其它移入 old

  4. 上传文件

  5. 移回其它需要的文件，如：

  6. -- 勋章/loading/logo/nv 等：/static/image/common/

  7. -- 表情：/static/image/smiley/

  8. -- 水印：/static/image/common/watermark.*

  9. -- 风格：/template/default/style/t2/nv.png 等

  10. -- 默认头像：/uc_server/images/noavatar_***.gif

  11. -- 根目录 favicon.ico 等

  12. -- 及其它非 DZ 文件

  13. 再次检查可写目录的写入权限和禁止运行 PHP 效果。


xoyozo 2 个月前
208
记一次 Discuz! 论坛打开很慢或打不开的问题解决

论坛出现动态页面打开或刷新非常慢（超过半分钟），甚至打不开，该页无法显示，502 Bad Gateway 等情况，TTFB 计时需要好几秒。

微信图片_20220528233028.png

切换 nginx 版本、php 版本 等均无效果，甚至购买新的 ECS 重新搭建环境也是效果甚微。

最终在阿里云 RDS 管理中，手动主备库切换，问题得以解决。

image.png

因此大概率是原主库有问题（有损坏的表需要修复或锁等情况）。

查询故障时间段的慢 SQL，发现某表的锁等待时间特别长，不知道是不是这个表的原因导致的。

image.png

次日，提交工单得到回复是原主库（现备库）会自动修复，经再次主备库切换测试得到了肯定的结果。

再次日，又遇到同样的打开慢的情况，这次直接找到慢 SQL 中锁等待时间较长的表，优化（OPTIMIZE TABLE）（虽然是 InnoDB），立刻解决了问题。

xoyozo 3 年前
3,673
记一次 Discuz! 论坛升级（阿里云）

本文记录于 2021 年 9 月。



升级前期望（最新正式版）最终选择
操作系统CentOS 6.5Alibaba Cloud Linux 3Alibaba Cloud Linux 3
管理面板lnmp宝塔面板 Linux 版 7.7.0宝塔面板 Linux 版 7.7.0
Web 服务nginx 1.6nginx 1.21nginx 1.21
脚本语言PHP 5.6PHP 8.0PHP 7.4
数据库
RDS MySQL 5.6RDS MySQL 8.0RDS MySQL 5.6
论坛程序
Discuz! X3.2 GBKDiscuz! X3.5 UTF-8（即将发布）Discuz! X3.4 GBK


版本选择原因：

  • Alibaba Cloud Linux 完全兼容 CentOS，相比于 CentOS 较短的生命周期，Alibaba Cloud Linux 3 将于 2029 年 4 月 30 日结束生命周期。

  • Discuz! X3.4 不支持 PHP 8.0，安装时即报错，打开页面时一片空白。

  • MySQL 8.0 和阿里云 RDS 的 MySQL 7.5 不支持 MyISAM，而数据表 pre_common_member_grouppm 和 pre_forum_post 使用联合主键且自动递增字段不是第一主键，使用 InnoDB 引擎创建表时会报“1075 - Incorrect table definition; there can be only one auto column and it must be defined as a key”错误，而擅自更改主键次序会影响业务逻辑。因此，在必须选择阿里云 RDS 的情况下，只能选择 MySQL 5.6。（2023年8月注：查看如何更改为 InnoDB）

  • Discuz! X3.5 正式版尚未发布（截止发稿），即便发布，插件也可能不能得到及时更新。相比之下，X3.4 首个版本发布距今已有 4 年，相关第三方插件已经非常成熟。


完整升级步骤：

  1. 备份原网站程序、RDS 数据库；

  2. 购买新的 ECS、RDS，挂载磁盘，安装云监控；

  3. 迁移（或还原）数据库到新的 RDS；

  4. 安装宝塔面板并配置；

  5. 安装 nginx 及 PHP；

  6. 创建网站、配置 SSL、伪静态、防盗链、可写目录禁执行等（.conf）；

  7. 配置 hosts；

  8. 上传原网站程序到新的站点目录下；

  9. 按 Discuz! X 升级文档升级 X3.2 至 X3.4；详情见下文 ↓；

  10. 配置 OSS、Redis、更新缓存等；

  11. 测试论坛基本功能是否正常；检查附件是否正常显示；全面检查控制台配置；

  12. 逐个开启插件并检查兼容性；

  13. 按二开备忘录逐个按需进行二开；

  14. 逐个修改调用论坛接口的项目及直接调用论坛数据库的项目；

  15. 调试 MAGAPP 接口；

  16. 尝试强制 https 访问；

  17. 将以上所有修改后的程序保留备份；发布升级公告并关闭论坛；重复以上步骤；修改域名解析；开启论坛；

  18. 配置 IP 封禁、定时器、日志、自动备份、配置其它 ECS 的 hosts 等；

  19. 查看搜索引擎中收录的地址，是否有无法访问的情况；

  20. 尝试将历史遗留的本地附件全部转移到 OSS；

  21. 参这篇文章，可能有其它需要配置的地方。


Discuz! X 升级步骤及注意点：

  • 升级前务必先修改 ./config/ 目录下的数据库/缓存连接信息，以防出现新站连接老库的情况；

  • 按官方文档进行升级；

  • 【问题】运行到 ./install/update.php?step=data&op=notification 时白屏。

    【排查】尝试切换到 PHP 5.6 后成功（但该版本过于陈旧不能使用）；尝试升级 CPU 和内存 PHP 7.4 上升级仍不成功。

    【原因】DB::result_first() 方法不对 SQL 语句追加“limit 1”，而是 SELECT 所有记录后在 PHP 端取第一条数据；

    【解决】打开文件 update.php，查找 elseif($_GET['op'] == 'notification')，该节点的功能是在表 home_notification 中查找 category <= 0 的数据并修复它，如果数据库中所有 category 都大于 0，直接注释其内部 if 代码段继续升级即可（或改为 if(false && ...)）。

  • 【问题】发布主题遇到错误：(1062) Duplicate entry '*' for key 'pid'

    【原因】forum_post 中的 pid 不是自动增长的，而是由表 forum_post_tableid 中自动增长的 pid 生成的。如果生成的 pid 值已在 forum_post 表中存在，则会出现此错误。

    【解决】迁移数据库时应关闭论坛，以防止 forum_post 表有新数据插入。

  • 【问题】打开帖子页面 ./thread-***-1-1.html 显示 404 Not Found，而 ./forum.php?mod=viewthread&tid=*** 可以正常打开

    【原因】未配置伪静态（可在宝塔面板中选择）

  • 【问题】打开 UCenter 时报错：UCenter info: MySQL Query Error SQL:SELECT value FROM [Table]vars WHERE name='noteexists'

    【解决】打开文件 ./uc_server/data/config.inc.php 配置数据库连接

  • 【问题】打开登录 UCenter 后一片空白

    【解决】将目录 ./uc_server/data/ 设为可写

  • 需要将原来安装的插件文件移回 ./source/plugin/ 目录，并设置可写；

  • 界面-表情管理，界面-编辑器设置-Discuz!代码


后续 Discuz! X3.4 R 小版本升级注意事项：

  1. 确认插件是否支持新版本（如短信通）

  2. 先创建一个新网站测试二开代码

  3. 保留 /config/、/data/、/uc_client/data/、/uc_server/data/、/source/plugin/，其它移入 old

  4. 上传文件

  5. 移回其它需要的文件，如：

  6. -- 勋章/loading/logo/nv 等：/static/image/common/

  7. -- 表情：/static/image/smiley/

  8. -- 水印：/static/image/common/watermark.*

  9. -- 风格：/template/default/style/t2/nv.png 等

  10. -- 默认头像：/uc_server/images/noavatar_***.gif

  11. -- 根目录 favicon.ico 等

  12. -- 及其它非 DZ 文件

  13. 再次检查可写目录的写入权限和禁止运行 PHP 效果。

xoyozo 3 年前
4,355
there can be only one auto column and it must be defined as a key

1075 - Incorrect table definition; there can be only one auto column and it must be defined as a key

在 MyISAM 转 InnoDB 时出现。

原因：这个表有联合主键，且自增的字段不是第一个主键。

解决方法一，取消自增字段的自动递增，改为在程序中实现；

解决方法二，单独给自增字段单独添加一个索引。


以 Disucz! X3.4 为例，方法一改程序代码显然困难比较大，所以选择方法二。

表 pre_forum_post 中，tid 为第1主键，position 为第2主键且自增。

tid 表示主题，position 表示该帖在该主题中的位置（类似于楼层的概念）。

所以在原来 MyISAM 中可以方便地实现 position 在各自的主题下自增。


给 position 单独添加索引后可以将引擎改为 InnoDB，但是 position 在全表范围内自增了。

也就是说，如果发布一个新主题，那么这个主题帖的 position 就不是1，而是整个数据库中最大的 position 再加 1。

虽然不影响页面中帖子的排序和楼层号显示，但不知道会不会有其它问题，所以最好把它改过来。


给表 pre_forum_post 添加一个触发器，在插入前（BEFORE INSERT）

BEGIN
    DECLARE max_position INT;
    
    SELECT MAX(position) INTO max_position FROM pre_forum_post WHERE tid = NEW.tid;
    
    IF max_position IS NULL THEN
        SET max_position = 0;
    END IF;
    
    SET NEW.position = max_position + 1;
END

在上面触发器的定义中，NEW 指即将要插件的一条记录，在新插入的帖子所在主题中寻找最大的 position 赋值给一个 INT 变量，如果找不到就赋值 0，然后 +1 赋值给新的 position。

这样就实现了与原来相同的效果。


用同样的方法给表 pre_common_member_grouppm 添加触发器。

如果帖子有分表，给每个分表添加触发器，下次有新的分表也要记得添加。

xoyozo 3 年前
2,476
关于 MySQL 数据库索引

本文未完成，部分测试方法、条件或结果可能有误，请谨慎参考！ :)

本文基于 MySQL 的 InnoDB BTREE 方法的索引进行测试。

以一张包含 2000 万条记录的表做实验：

CREATE TABLE `dt_read`  (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `time` datetime(0) NOT NULL,
  `a_id` int(11) NOT NULL,
  PRIMARY KEY (`id`) USING BTREE
);

这张表是用于记录文章点击量的，

`id` 为主键，int(11) 自增；

`time` 为非空 datetime，表示文章打开时间，测试数据是从 2017-03-11 至 2018-04-28；

`a_id` 为非空 int(11)，表示文章 ID，在此表中不唯一，测试数据是从 1 至 260218。


体验“全表扫描”


首先来体验一下什么是全表扫描，执行下面语句：

SELECT * FROM `dt_read` WHERE `time` < '2020-1-1' LIMIT 10

> 时间: 0.012s


SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' LIMIT 10

> 时间: 7.317s


表中数据是按主键从小到大排列的，当查询条件为 `time` < '2020-1-1' 时，能很快地从表的前端找到 10 条满足条件的数据，所以不再继续判断后面的记录，立刻返回结果，耗时 0.012 秒；但当条件改为 `time` < '2000-1-1' 时，同样逐条判断，直到最后一条也没有找到，这种情况就是所谓的“全表扫描”，耗时 7 秒。


索引对 ORDER BY 的 ASC 和 DESC 的影响


我们给 `time` 建一个索引，同样执行刚才需要全表扫描的语句：

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' LIMIT 10

> 时间: 0.012s


创建 `time` 的索引后，相当于生成了一张按 `time` 字段排列的新表，这时 MySQL 就能够很快地定位并找到符合条件的记录，避免了全表扫描。


试试按 `time` 倒序排：

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' ORDER BY `time` DESC LIMIT 10

> 时间: 0.013s


结论：索引对 ORDER BY 的顺序（ASC）和倒序（DESC）都是有效的。


索引字段的次序对 WHERE 和 ORDER BY 的影响


删除所有索引，创建一个新的索引，字段依次为 `time`, `a_id`。

分别执行以下查询：


SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' AND `a_id` < 0 LIMIT 10

> 时间: 0.013s


SELECT * FROM `dt_read` WHERE `a_id` < 0 AND `time` < '2000-1-1' LIMIT 10

> 时间: 0.013s


结论：MySQL 会自动优化 WHERE 条件的次序来匹配最合适的索引。

但在 ORDER BY 中却不是这么回事了：


SELECT * FROM `dt_read` ORDER BY `time`, `a_id` LIMIT 10

> 时间: 0.013s


SELECT * FROM `dt_read` ORDER BY `a_id`, `time` LIMIT 10

> 时间: 14.066s


原因也很好理解，对两个字段进行排序，先后次序肯定会影响结果集，因此只能以 SQL 语句指定的字段次序来 ORDER BY，这样，按索引的字段次序进行 ORDER BY 查询无疑是更快的。


索引中的字段必须依次使用


保持上例创建的索引不变，即 `time`, `a_id`。


SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' AND `a_id` < 0 LIMIT 10

> 时间: 0.013s


SELECT * FROM `dt_read` WHERE `a_id` < 0 LIMIT 10

> 时间: 6.438s


上句合理利用了索引的字段，而下句跳过了 `time`，直接 WHERE 了 `a_id`，这是不受该索引支持的。

我们可以想象一下这张由索引生成的虚拟表，其实就是一张普通的平面二维表格，按索引指定的字段次序进行了排序，所以全表中仅仅是索引指定的第一个字段是按大小排列的，第二个字段是在第一个字段值相同的区域内按大小排列，后同。所以，跳过索引指定的第一个字段直接对第二个字段进行检索，是无法应用该索引的。这个结论也同样也体现在 ORDER BY 语句中：


SELECT * FROM `dt_read` ORDER BY `time`, `a_id` LIMIT 10

> 时间: 0.013s


SELECT * FROM `dt_read` ORDER BY `a_id` LIMIT 10

> 时间: 29.566s


WHERE 和 ORDER BY 混合


保持上例创建的索引不变，即 `time`, `a_id`。


先来执行这两句：


SELECT * FROM `dt_read` ORDER BY `a_id` LIMIT 10

> 时间: 12.29s


SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' ORDER BY `a_id` LIMIT 10

> 时间: 0.013s


仅仅 WHERE 了一个 `time`，对 ORDER BY `a_id` 的效率却有质的提升，是因为 WHERE 中的 `time` 和 ORDER BY 中的 `a_id` 一起找到了索引吗？答案是否定的。

我们把时间改大，让它能马上找到符合条件的数据：


SELECT * FROM `dt_read` WHERE `time` < '2020-1-1' ORDER BY `a_id` LIMIT 10

> 时间: 22.34s


为什么这个语句就不走索引了呢？

其实，一个简单的 SELECT 查询语句，首先执行 WHERE，然后 ORDER BY，最后是 LIMIT。每一步都独自去找了索引，而非 WHERE 和 ORDER BY 混在一起去找索引。必须保证每一步是快的，最终才是快的。

当 `time` < '2000-1-1' 时，WHERE 用到了索引，所以很快，ORDER BY 却没有用到索引，但为什么也很快呢？因为 WHERE 的结果集非常小（示例中为 0 条）。

当 `time` < '2020-1-1' 时，WHERE 也用到了索引，但其结果集非常大（示例中为所有记录），再 ORDER BY `a_id` 就非常慢了，因为我们没有创建以 `a_id` 开头的索引。


现在把索引改成只有 `time` 一个字段。


SELECT * FROM `dt_read` WHERE `time` < '2020-1-1' ORDER BY `a_id` LIMIT 10

> 时间: 6.033s


因为索引里有 `


SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' ORDER BY `a_id` LIMIT 10

> 时间: 0.013s


SELECT * FROM `dt_read` WHERE `a_id` < 0 ORDER BY `time` LIMIT 10

> 时间: 6.033s


第二句先 WHERE `a_id`，后 ORDER BY `time` 是不能匹配所建的索引的。


索引中的字段越多越好


分别在创建索引（`time`）和索引（`time`, `a_id`）的情况下执行下面语句：

本例使用 ORDER BY 而不是 WHERE 来测试是因为，在 WHERE 的多个条件下，如果符合前一条件的筛选结果集过小会导致判断第二条件时数据量不足，无法判断索引是否起作用。


SELECT * FROM `dt_read` ORDER BY `time` LIMIT 10


仅创建索引（`time`）的情况下：

> 时间: 0.013s


仅创建索引（`time`, `a_id`）的情况下：

> 时间: 0.013s


SELECT * FROM `dt_read` ORDER BY `time`, `a_id` LIMIT 10


仅创建索引（`time`）的情况下：

> 时间: 15.015s


仅创建索引（`time`, `a_id`）的情况下：

> 时间: 0.014s


可以看到，在索引字段依次使用的前提下，索引字段数不少于查询字段数才能避免全表扫描。

虽然索引中的字段越多越好，但必须依次使用，否则也是无效索引。


索引对 INSERT / UPDATE / DELETE 的效率影响


分别在创建索引（`time`）和索引（`time`, `a_id`）的情况下执行下面语句：


INSERT INTO `dt_read` (`time`, `a_id`) VALUES ('2018-4-28', 260218)


不建索引的情况下：

> 时间: 0.01s


仅创建索引（`time`）的情况下：

> 时间: 0.01s


同时创建索引（`time`）和索引（`time`, `a_id`）的情况下：

> 时间: 0.01s


UPDATE `dt_read` SET `time` = '2018-4-28' WHERE `id` = 20000000（注：存在该 id 值的记录）


不建索引的情况下：

> 时间: 0.01s


仅创建索引（`time`）的情况下：

> 时间: 0.01s


同时创建索引（`time`）和索引（`time`, `a_id`）的情况下：

> 时间: 0.01s


虽然在 INSERT / UPDATE / DELETE 时数据库会更新索引，但从实测数据来看，索引对其效率的影响可忽略不计。


一些误区


“in 语法效率很低”?

in 语法也是应用索引的，网传 in 会比一个一个 WHERE OR 要慢得多的说法是不靠谱的。in 主键和 in 索引同理。


另外：

对于字符串类型，LIKE '%abc%' 是不能应用索引的，但 LIKE 'abc%' 可以。更多关于字符串类型的索引，请查阅全文索引（FULLTEXT）。

索引的字段是可以指定长度的，类似字符串索引指定前面若干唯一字符就可以优化效率。


本文系个人实践总结，欢迎批评指正！


xoyozo 7 年前
3,774
1

大家在看

如何修改 Discuz! 网站标题
Could not load file or assembly 'Microsoft.EntityFrameworkCore.Relational, Version=6.0.x.0, Culture=
修复 ASP 项目 SQL 注入漏洞和 XSS 跨站脚本攻击等威胁常用的语句
Linux 添加开机自启动脚本
ASP.NET 中使用 Tesseract，发布后报错：Exception has been thrown by the target of an invocation.

最新发布

在 ASP.NET Core 网站中使用远程接口鉴权
nginx 中的生命周期
在 access_by_lua_block 获取系统 CPU 使用率
在宝塔面板中使用 lua 实现远程接口鉴权
在宝塔面板中使 lua 支持 resty.http