测试表数据量 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 倍。

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

xoyozo 2 年前

1,562

记一次 Discuz! 论坛升级（阿里云）

本文记录于 2021 年 9 月。

	升级前	期望（最新正式版）	最终选择
操作系统	CentOS 6.5	Alibaba Cloud Linux 3	Alibaba Cloud Linux 3
管理面板	lnmp	宝塔面板 Linux 版 7.7.0	宝塔面板 Linux 版 7.7.0
Web 服务	nginx 1.6	nginx 1.21	nginx 1.21
脚本语言	PHP 5.6	PHP 8.0	PHP 7.4
数据库	RDS MySQL 5.6	RDS MySQL 8.0	RDS MySQL 5.6
论坛程序	Discuz! X3.2 GBK	Discuz! 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 年，相关第三方插件已经非常成熟。

完整升级步骤：

备份原网站程序、RDS 数据库；
购买新的 ECS、RDS，挂载磁盘，安装云监控；
迁移（或还原）数据库到新的 RDS；
安装宝塔面板并配置；
安装 nginx 及 PHP；
创建网站、配置 SSL、伪静态、防盗链、可写目录禁执行等（.conf）；
配置 hosts；
上传原网站程序到新的站点目录下；
按 Discuz! X 升级文档升级 X3.2 至 X3.4；详情见下文 ↓；
配置 OSS、Redis、更新缓存等；
测试论坛基本功能是否正常；检查附件是否正常显示；全面检查控制台配置；
逐个开启插件并检查兼容性；
按二开备忘录逐个按需进行二开；
逐个修改调用论坛接口的项目及直接调用论坛数据库的项目；
调试 MAGAPP 接口；
尝试强制 https 访问；
将以上所有修改后的程序保留备份；发布升级公告并关闭论坛；重复以上步骤；修改域名解析；开启论坛；
配置 IP 封禁、定时器、日志、自动备份、配置其它 ECS 的 hosts 等；
查看搜索引擎中收录的地址，是否有无法访问的情况；
尝试将历史遗留的本地附件全部转移到 OSS；

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 小版本升级注意事项：

确认插件是否支持新版本（如短信通）
先创建一个新网站测试二开代码
保留 /config/、/data/、/uc_client/data/、/uc_server/data/、/source/plugin/，其它移入 old
上传文件
移回其它需要的文件，如：
-- 勋章/loading/logo/nv 等：/static/image/common/
-- 表情：/static/image/smiley/
-- 水印：/static/image/common/watermark.*
-- 风格：/template/default/style/t2/nv.png 等
-- 默认头像：/uc_server/images/noavatar_***.gif
-- 根目录 favicon.ico 等
-- 及其它非 DZ 文件
再次检查可写目录的写入权限和禁止运行 PHP 效果。

xoyozo 3 年前

3,051

用 inotify-tools 监视文件系统事件并对其采取行动

本文适用于 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。

xoyozo 4 年前

2,941

Date Range Picker（一款 jQuery 插件，支持日期范围、时间范围选择）

引用

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

xoyozo 4 年前

3,426

这样做会让 ASP.NET 运行得更好

使用会话状态服务器（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 字段添加索引。

未完待续

xoyozo 5 年前

1,996

配置 cloudfs4oss 解决 cloudfs 进程占用内存的问题

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

xoyozo 5 年前

3,062

给 magapp 数据库及使用 magapp 的 Discuz! 数据库加索引

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 的慢查询自行加索引就行了。

xoyozo 6 年前

3,602

关于 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 6 年前

3,208

ASP.NET 网站每次发布后丢失 Session 怎么办？

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

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

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

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

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

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

	InProc	StateServer	SQLServer
存储位置	应用进程内	ASP.NET State Service 服务	SQL Server 数据库
远程存储	不支持	支持	支持
存储格式	任意	序列化的	序列化的
可能导致重启（丢失）的情况	配置文件中 processModel 标签的 memoryLimit 属性； Global.asax 或者 Web.config 文件被更改； Bin 文件夹中的 Web 程序（DLL）被修改；杀毒软件扫描了一些 .config 文件；系统资源紧张进行资源回收导致 IIS 进程崩溃或重启等。	ASP.NET State Service 服务停止；	-
Session_End() 事件	有	无	无
部署难度	无	简单	稍复杂
Web.config 配置示例（<system.web> 节点内）	<sessionState mode="InProc" />	<sessionState mode="StateServer" />	<sessionState mode="SQLServer" sqlConnectionString ="data source=x.x.x.x; user id=[user]; password=[pwd]" />

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

注：

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

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

xoyozo 7 年前

4,408

记一次 Discuz! 论坛数据库崩溃“(1040) notconnect”CPU 和连接数 100% 的解决过程

论坛使用阿里云的 ECS + RDS + OSS 搭建，最近经常隔三差五出现 RDS 的 CPU 和连接数突然满负荷的情况，导致数据库无法连接。这种情况一般会认为是受到了攻击，因为如果是访问量大或者是哪里有慢查询，应该是资源消耗逐步上升直至崩溃的，沿着这个思路去查 Web 日志封 IP，但效果不大，关闭功能、卸载插件也没用。

开启阿里云后台的 SQL 审计，能看到 SQL 查询日志，但是很难找有问题的 SQL。

最终在重启 RDS 后执行以下语句列出所有正在执行或阻塞的语句：

show full processlist

在结果列中，Command 为 Query 是正在执行查询操作的语句，发现几乎所有的 SQL 都是：

SELECT * FROM pre_forum_thread WHERE tid>0 AND fid IN('42','95','247','41','567','62','149','229','37','230','93','190','284','75','38','568') AND `fid`<>'546' AND replies > 0 AND displayorder>=0 ORDER BY lastpost DESC  LIMIT 10

再加上之前出现的情况是，论坛帖子列表和详情页面能正常打开时，论坛首页也不一定能打开，所以基本定位到是“首页四格”的数据库查询导致的。

进入论坛后台首页四格设置，对比了版块 id 后确认了这个 bug。

单独执行该语句大约耗时 5s（主题帖 200 万），设置的缓存时间 10 分钟。

processlist 中看到这些语句的 state 都是 Creating sort index，尝试去掉 ORDER BY 后执行果然只需要 16ms。

5s 内的访客都是从数据库读取的，能处理完就正常，否则累积就导致 RDS 崩溃，每 10 分钟都会重现一次风险。

当然这个问题可以通过添加索引来解决。

xoyozo 7 年前

5,819

1 2

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

体验“全表扫描”

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

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

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

WHERE 和 ORDER BY 混合

索引中的字段越多越好

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

一些误区

大家在看

最新发布

查询 / 检测

编程

前端

行业

本站 API

博客 (11)

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

体验“全表扫描”

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

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

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

WHERE 和 ORDER BY 混合

索引中的字段越多越好

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

一些误区

大家在看

最新发布