本文记录于 2024 年 11 月。

版本选择原因：

• 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 效果。

测试表数据量 152 万条，测试跳过 100 万取 10 条。

测试一：直接使用 limit 跳过 1000000 取 10，耗时 2.4s；

SELECT *
FROM `pre_forum_post`
ORDER BY `pid`
LIMIT 1000000, 10
> OK
> 时间: 2.394s

测试二：先使用 limit 跳过 1000000 取 1，再使用配合 where 条件，使用 limit 取 10，耗时 0.2s。

SELECT *
FROM `pre_forum_post` 
WHERE `pid` >= (
		SELECT `pid` 
		FROM `pre_forum_post` 
		ORDER BY `pid` 
		LIMIT 1000000, 1
		)
ORDER BY `pid`
LIMIT 10
> OK
> 时间: 0.207s

两次测试耗时相差约 10 倍。测试取 100 条或取 1 条，耗时都相差约 10 倍。

但若测试跳过条数较小时，测试一效率更高，因此应按照项目的实际需要选择适当的查询方法。

本文记录于 2021 年 9 月。

版本选择原因：

• 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 效果。

本文适用于 CentOS(Linux)，Window 系统请移步：https://xoyozo.net/Blog/Details/FileSystemWatcher

安装

参照官方说明：https://github.com/inotify-tools/inotify-tools/wiki

以 CentOS 为例：

安装 EPEL :

yum install -y epel-release && yum update

安装 inotify-tools:

yum install inotify-tools

在 CentOS-7 中

yum --enablerepo=epel install inotify-tools

v3.14-8.el7.×86_64 as of 4-18-2018

配置

创建 Shell 脚本文件：

#!/bin/bash
inotifywait -mrq -e modify,attrib,move,create,delete /要监视的目录 | while read dir event file;
do
  curl -d "df=${dir}${file}&ev=${event}" https://xxx.xxx.xxx/api/inotify/
done

并将该文件设置为可执行：chmod +x xxx.sh

注：上述示例将对文件的部分操作事件信息传递到远程接口。inotifywait 与 curl 的用法请自行百度。

如果需要忽略部分文件路径，可以使用正则表达式进行过滤，例：

#!/bin/bash
inotifywait -mrq -e modify,attrib,move,create,delete /要监视的目录 | while read dir event file;
do
  df=${dir}${file};
  if [[ ! $df =~ ^/www/wwwroot/[0-9a-z]+.xxx.com/[0-9a-zA-Z]+/Runtime/Cache/[0-9a-zA-Z]+/[0-9a-f]{32}.php$
     && ! $df =~ ^/www/wwwroot/[0-9a-z]+.xxx.com/[0-9a-zA-Z]+/Runtime/Logs/[0-9a-zA-Z]+/[0-9]{2}_[0-9]{2}_[0-9]{2}.log$
    ]]; then
    curl -d "df=${df}&ev=${event}" https://xxx.xxx.xxx/api/inotify/
  else
    echo "Ignored: $df"
  fi
done

注意：bash 中使用 [[ string =~ regex ]] 表达式进行正则匹配，“!”取反，“&&”为且，书写时不要吝啬使用空格，否则程序可能不会按预期运行。

执行

先直接执行 sh 命令，排查一些错误。

Failed to watch /www/wwwroot; upper limit on inotify watches reached!

Please increase the amount of inotify watches allowed per user via `/proc/sys/fs/inotify/max_user_watches'.

因被监视的目录中文件数超过默认值 8192 提示失败，更改该值即可。

echo 8192000 > /proc/sys/fs/inotify/max_user_watches

设置开机自动运行，参：https://xoyozo.net/Blog/Details/linux-init-d。

引用

jQuery、moment.js、daterangepicker

例子

$('.x_dates').daterangepicker({
    "timePicker": false, // 是否显示时间
    //"dateLimit": {
    //    "days": 7 // 可选中的最大区间（天）
    //},
    "ranges": { // 快捷栏
        "今天": [moment(), moment()],
        "昨天": [moment().subtract(1, 'days'), moment().subtract(1, 'days')],
        "最近 7 天": [moment().subtract(6, 'days'), moment()],
        "最近 30 天": [moment().subtract(29, 'days'), moment()],
        "本月": [moment().startOf('month'), moment().endOf('month')],
        "上个月": [moment().subtract(1, 'month').startOf('month'), moment().subtract(1, 'month').endOf('month')]
    },
    startDate: daterangepicker_startDate, // moment(),
    endDate: daterangepicker_endDate, // moment(),
    autoUpdateInput: true,
    "locale": {
        "direction": "ltr",
        "format": "YYYY-MM-DD", // YYYY-MM-DD HH:mm
        "separator": " 至 ",
        "applyLabel": "确定",
        "cancelLabel": "取消",
        "fromLabel": "From",
        "toLabel": "To",
        "customRangeLabel": "自定义",
        "daysOfWeek": ["日", "一", "二", "三", "四", "五", "六"],
        "monthNames": ["一月", "二月", "三月", "四月", "五月", "六月", "七月", "八月", "九月", "十月", "十一月", "十二月"],
        "firstDay": 1
    }
}, function (start, end, label) {
    //console.log('New date range selected: ' + start.format('YYYY-MM-DD') + ' to ' + end.format('YYYY-MM-DD') + ' (predefined range: ' + label + ')');
    fn_daterangepicker_changed(start.format('YYYY-MM-DD'), end.format('YYYY-MM-DD'))
});

官网（含配置工具）

http://www.daterangepicker.com/

GitHub

https://github.com/dangrossman/daterangepicker

配置工具

下载的包中的 demo.html

Demo

https://awio.iljmp.com/5/drpdemo

• 使用会话状态服务器（StateServer）管理会话状态，可防止网站发布后会话丢失，参 ASP.NET 网站每次发布后丢失 Session 怎么办？

• 查询数据库时，尽量使用 using 包裹 db 上下文，或者 db.Dispose()，或重写 Dispose()，可以减少数据库连接数（Sleep），参 如何减少 ASP.NET 连接 MySQL 时的 Sleep 查询（即时关闭数据库上下文）

• 发布时使用预编译功能，参 彻底告别 .NET 网站首次访问速度慢的问题

• 清理日志不要这样写（先读取再删除）：

  db.dt_log.RemoveRange(db.dt_log.Where(c => c.time < dt).OrderBy(c => c.time).Take(count));

  SQL Server 应该：

  db.Database.ExecuteSqlCommand($"DELETE FROM {nameof(db.dt_log)} WHERE {nameof(l.id)} IN (SELECT TOP {count} {nameof(l.id)} FROM {nameof(db.dt_log)} WHERE {nameof(l.time)} < '{dt.ToString("yyyy-MM-dd HH:mm:ss")}' ORDER BY {nameof(l.time)})");

  注意时间可能需要使用 convert 函数转化，给 time 字段添加索引。

  MySQL 应该：

  db.Database.ExecuteSqlCommand($"DELETE FROM {nameof(db.dt_log)} WHERE {nameof(l.time)} < '{dt.ToString("yyyy-MM-dd HH:mm:ss")}' ORDER BY {nameof(l.time)} LIMIT {count}");

  给 time 字段添加索引。

• 未完待续

CloudFS 是一款将阿里云 OSS 对象存储挂载为 Linux 本地目录的工具软件，目前已经从阿里云市场下架了。

在云监控中查看到进程 cloudfs 占用大部分内存，可以打开文件 /usr/local/cloudfs/conf/cloudfs.conf 进行配置。

默认值：

BLOCK_SIZE=1048576

MAX_CACHE_LIMITS=10485760

根据实际情况进行修改，然后重启 cloudfs，相关命令：

启动：service cloudfs start

停止：service cloudfs stop

重启：service cloudfs restart

查看状态：service cloudfs status

Discuz! 数据库加索引

待优化的 SQL：（pre_forum_thread 表有 150 万条数据）

SELECT * FROM pre_forum_thread  WHERE `fid`='62' AND `displayorder` IN('0','1','2','3','4')  ORDER BY displayorder DESC, dateline DESC    LIMIT 20, 20

加索引前，

EXPLAIN 结果 Extra 为：Using index condition; Using where; Using filesort

> 时间: 0.915s

加索引后：`fid`, `displayorder`, `dateline`

EXPLAIN 结果 Extra 为：Using where 或 Using index condition

> 时间: 0.001s

magapp 数据库加索引

待优化的 SQL：（mag_score_action_log 表有 200 万条数据）

SELECT COUNT(*) AS tp_count
FROM `mag_score_action_log`
WHERE action_id = 20
	AND user_id = 650070
	AND create_time >= 1534953600
	AND create_time < 1535040000
LIMIT 1

加索引前，

EXPLAIN 结果 Extra 为：?????

> 时间: 70s

加索引后：`action_id`, `user_id`, `create_time`

EXPLAIN 结果 Extra 为：Using where; Using index

> 时间: 0.073s

待优化的 SQL：（mag_score_mission_log 表有约 55 万条数据）

SELECT COUNT(*) AS tp_count
FROM `mag_score_mission_log`
WHERE mission_id = 7
	AND user_id = 650070
	AND create_time >= 1534953600
	AND create_time < 1535040000
LIMIT 1

加索引前，

EXPLAIN 结果 rows 为：549178

> 时间: 17.719s

加索引后：`mission_id`, `user_id`, `create_time`

EXPLAIN 结果 rows 为：1

> 时间: 0.025s

待优化的 SQL：（mag_score_mission_user 表有约 28 万条数据）

SELECT *
FROM `mag_score_mission_user`
WHERE `user_id` = 431779
	AND `mission_id` = 5
	AND `create_time` >= 1534953600
ORDER BY complete_count DESC
LIMIT 1

不加索引

1SIMPLEmag_score_mission_userALL282436Using where; Using filesort

> 时间: 7.325s

`user_id`, `mission_id`

1SIMPLEmag_score_mission_userrefix_us_miix_us_mi10const,const7Using where; Using filesort

时间: 0.014s

`user_id`, `mission_id`, `create_time`

1SIMPLEmag_score_mission_userrangeix_us_miix_us_mi151Using index condition; Using filesort

时间: 0.023s

`user_id`, `mission_id`, `complete_count`

1SIMPLEmag_score_mission_userrefix_us_miix_us_mi10const,const7Using where

> 时间: 0.014s

`user_id`, `mission_id`, `complete_count`, `create_time`

1SIMPLEmag_score_mission_userrefix_us_miix_us_mi10const,const7Using where

> 时间: 0.028s

`user_id`, `mission_id`, `create_time`, `complete_count`

1SIMPLEmag_score_mission_userrangeix_us_miix_us_mi151Using index condition; Using filesort

> 时间: 0.025s

其它就不一一举例了，根据 SHOW FULL PROCESSLIST 的慢查询自行加索引就行了。

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

本文基于 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）。

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

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

Session 有多种存储模式，默认是 InProc，顾名思义是“在进程内”，即在 IIS 中，随网站重启而重启，网站发布后（或改动 .dll 文件）会导致应用重新运行，Session 清空。

Session 可以使用 StateServer 来保存，需要服务器开启 ASP.NET State Service 服务，此种方式要求保存在 Session 的信息必须序列化，然后从 Session 中获取的时候也要反序列化，这就导致性能有略微的损失。

Session 还可以配置为 SQLServer，将 Session 存储在数据库中，同样需要序列化。

当配置为 Custom 时，可以在使用 Memcached、Redis 等第三方缓存技术来实现 Session 的管理，本文不作讨论。

Off 模式即关闭 Session，这种方式如果要实现用户登录功能，就必须依赖 Cookie 等来实现。

下面针对常见的三种模式进行比较：

因此，如果你仅仅为了标题所述的“每次发布后丢失 Session”而烦恼，那么推荐使用 StateServer 模式来存储 Session。

注：

如果 Session 的 Key 是在应用启动时随机生成的话，使用 StateServer 和 SQLServer 还是会“丢失” Session。

这是对 Session 的配置，对 Cache 无效。