与 2.X 不同的是，待审核的主题和回复是分开两张表存放的：
pre_forum_thread_moderate
pre_forum_post_moderate
字段 status 值含义：
0：未审核
1：已忽略
不在该表中的为已通过。
原标题：关于 PHP 获取 IP 地址的几种方法
PHP 获取客户端的 IP 地址有 4 种方式：
REMOTE_ADDR：浏览当前页面的用户计算机的 IP 地址
HTTP_X_FORWARDED_FOR：记录代理信息，会把每一层代理都记录
HTTP_CLIENT_IP：客户端的 IP
X-Real-IP：没有标准，由上一跳决定
REMOTE_ADDR 一般是不能伪造的，因为是通过服务器与客户端握手协议来获取的。而 HTTP_X_FORWARDED_FOR 和 HTTP_CLIENT_IP 是在 header 信息里面，所以客户端是可以进行很轻松的伪造。下面是对这三种方式详解：
https://www.test404.com/post-1448.html
https://www.cnblogs.com/mypath/articles/5239687.html
一、关于 REMOTE_ADDR
这个变量获取到的是“直接来源”的 IP 地址，所谓“直接来源”指的是直接请求该地址的客户端 IP 。这个 IP 在单服务器的情况下，很准确的是客户端 IP ，无法伪造。当然并不是所有的程序都一定是单服务器，比如在采用负载均衡的情况（比如采用 haproxy 或者 nginx 进行负载均衡），这个 IP 就是转发机器的 IP ，因为过程是客户端 -> 负载均衡 -> 服务端。是由负载均衡直接访问的服务端而不是客户端。
二、关于 HTTP_X_FORWARDED_FOR 和 HTTP_CLIENT_IP
基于“一”，在负载均衡的情况下直接使用 REMOTE_ADDR 是无法获取客户端 IP 的，这就是一个问题，必须解决。于是就衍生出了负载均衡端将客户端 IP 加入到 HEAD 中发送给服务端，让服务端可以获取到客户端的真实 IP 。当然也就产生了各位所说的伪造，毕竟 HEAD 除了协议里固定的那几个数据，其他数据都是可自定义的。
三、为何网上找到获取客户端 IP 的代码都要依次获取 HTTP_CLIENT_IP 、 HTTP_X_FORWARDED_FOR 和 REMOTE_ADDR
基于“一”和“二”以及对程序通用性的考虑，所以才这样做。 假设你在程序里直接写死了 REMOTE_ADDR ，有一天你们的程序需要做负载均衡了，那么你有得改了。当然如果你想这么做也行，看个人爱好和应用场景。也可以封装一个只有 REMOTE_ADDR 的方法，等到需要的时候改这一个方法就行了。
X_FORWARDED_FOR 与 X-Real-IP 的区别：
X_FORWARDED_FOR：记录了所有链路里的代理 IP 值，比如下面所说的，经过了 3 次代理，分别是 1.1.1.1, 2.2.2.2, 3.3.3.3，其中 1.1.1.1 是客户端 IP，2.2.2.2 是代理服务器，接下来同理。
X-Real-IP：是只会记录前一次代理的 IP 地址。
一般来说，X-Forwarded-For是用于记录代理信息的，每经过一级代理(匿名代理除外)，代理服务器都会把这次请求的来源IP追加在X-Forwarded-For中
来自4.4.4.4的一个请求，header 包含这样一行
代表请求由1.1.1.1发出，经过三层代理，第一层是2.2.2.2，第二层是3.3.3.3，而本次请求的来源IP4.4.4.4是第三层代理
而X-Real-IP，没有相关标准，上面的例子，如果配置了X-Read-IP，可能会有两种情况
所以 ，如果只有一层代理，这两个头的值就是一样的。
那一般在后端取值（比如 node.js 通过 nginx 代理）是用哪个值呢？我看 sf 上看一般推荐是用 X-Forwarded-For，直接用 X-Real-IP 岂不是更方便点？
X-Forwarded-For 确实是一般的做法
他在正向（如 squid）反向（如 nginx）代理中都是标准用法，而正向代理中是没有 x-real-ip 相关的标准的，也就是说，如果用户访问你的 nginx 反向代理之前，还经过了一层正向代理，你即使在 nginx 中配置了 x-real-ip，取到的也只是正向代理的 IP 而不是客户端真实 IP
大部分 nginx 反向代理配置文章中都没有推荐加上 x-real-ip ，而只有 x-forwarded-for，因此更通用的做法自然是取 x-forwarded-for
多级代理很少见，只有一级代理的情况下二者是等效的
如果有多级代理，x-forwarded-for 效果是大于 x-real-ip 的，可以记录完整的代理链路
1、将以下代码保存为 Client.php
// php 脚本开始
$ch = curl_init();
$url = "http://localhost/ser.php";
$header = array('CLIENT-IP:208.165.188.175', 'X-FORWARDED-FOR:208.165.188.175');
// 声明伪造 head 请求头
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_HTTPHEADER, $header);
curl_setopt($ch, CURLOPT_RETURNTRANSFER,true);
$page_content = curl_exec($ch); curl_close($ch);
echo $page_content;
2、将以下代码保存为 ser.php
// php 脚本开始
echo getenv('HTTP_CLIENT_IP');
echo getenv('HTTP_X_FORWARDED_FOR');
echo getenv('REMOTE_ADDR');
测试结果为
208.165.188.175
208.165.188.175
127.0.0.1上面结果可看出，http_client_ip、http_x_forwarded_for 都被伪造了，而 remote_addr 还是127.0.0.1 就是客户端 IP
总结：
如果我们没用到负载均衡（CDN）的话直接用 REMOTE_ADDR 获取 IP。
如果使用了一级 CDN 的话，CDN 会把 REMOTE_ADDR 转发成 X-Real-IP，我们服务器可以获取 X-Real-IP 来获取 IP 值。如果是多级 CDN 的话需要我们来做 nginx 代理，详细：https://www.cnblogs.com/princessd8251/articles/6268943.html
就是第一台负载服务器获取 REMOTE_ADDR 转发成 X-Real-IP，之后的去继承前一台的 X-Real-IP 就可以了，这里记住必须是去继承，不然第二台会把第一台的 REMOTE_ADDR 转发成 X-Real-IP 导致错误。
在 discuz! 中的获取 IP 的方法：
private function _get_client_ip() {
$ip = $_SERVER['REMOTE_ADDR'];
if (isset($_SERVER['HTTP_CLIENT_IP']) && preg_match('/^([0-9]{1,3}\.){3}[0-9]{1,3}$/', $_SERVER['HTTP_CLIENT_IP'])) {
$ip = $_SERVER['HTTP_CLIENT_IP'];
} elseif(isset($_SERVER['HTTP_X_FORWARDED_FOR']) AND preg_match_all('#\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}#s', $_SERVER['HTTP_X_FORWARDED_FOR'], $matches)) {
foreach ($matches[0] AS $xip) {
if (!preg_match('#^(10|172\.16|192\.168)\.#', $xip)) {
$ip = $xip;
break;
}
}
}
return $ip;
}这里 DZ 为了符合有些用户会用代理，所以才首先使用了两个容易伪造的方法，如果有需要可以自行修改。
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 的慢查询自行加索引就行了。
附加消息：暂无该开发者或未上传过应用
原因： 没有上架应用（隐藏的不算上架），应用设置显示后记得在版本管理中将版本也设为显示。
附加消息：抱歉，开发者验证无效
原因：可能是没有达到认证要求，不允许加群（譬如：需应用最低总安装量 1000 次）
DZ 水很深，慎入：http://open.discuz.net/?ac=document&page=xootan
2018.8.14 踩坑：
还有，加群要开发者中填写的 QQ 才能加，因为验证是全自动程序判断的。
如果要跳过安装量 1000 次的要求，就直接花钱购买会员，不过购买会员也是一件非常艰难的事情，在与“Q群管家”这个机器人 QQ 的对话中发送“@购买vip”，绝对能让你体验到一种有钱也花不出去的感受。
做这么多花哨的东西，不如踏踏实实把产品做好。
2018.8.15 踩坑：
跟Q群管家对话，@login 时，由于密码过于复杂，消息没反应，特殊符号别提了，连纯大小写字母数字也不行，后改成纯数字密码登录成功。
加群完全看基本信息中填写的 QQ 客服 号，群主是机器人，只要应用是上架显示的，版本是显示的，就可以用这个QQ客服申请入群，（可以改）。
删除主题时，会变更主题表 pre_forum_thread：
displayorder = -1
moderated = 1
帖子表（或分表） pre_forum_post* 该主题的所有帖子的
invisible = -1
同时 pre_forum_threadmod 会新增一条 DEL 记录，用于显示到 Discuz! 控制面板 - 内容 - 主题回收站。
删除回帖时，会变更回帖表 pre_forum_post（或分表）：
invisible = -5
屏蔽回复时，会变更回复表 pre_forum_post（或分表）：
status = 1
在网站开发过程中遇到上传图片等文件的功能，需要在服务器上设置该目录可写入，并且必须防止被上传 .php 等可执行的脚本文件。
根据文件所有者的不同，我们分两种情况讨论：
一、程序上传的用户与执行 PHP 的用户不同（例如程序代码通过 SSH 上传（root 用户），而 PHP 以 www 身份运行）
由于 Linux 上的文件默认权限是 644，目录默认权限是 755，所以在这种情况下，PHP 不能修改 root 上传的程序文件，也不能将客户端上传的图片文件保存到服务器上。
例如我们将客户端上传的文件指定到 /upload/ 目录，那么，
第 1 步，赋予它写入权限：
chmod 777 upload递归所有子目录请加 -R 参数，但会将文件也更改为 777，赋予了执行权限，这是不建议的。文件若需写入权限请设为 666。
第 2 步，设置该目录下不允许执行 PHP：
我们无法保证客户端上传完全符合我们要求的文件，那么必须禁止任何文件的执行权限。（此处指 PHP 的执行权限，注意与 sh 执行权限的区别，后者由 chmod 命令修改）
nginx 的 .conf 文件配置示例：
location ~ /upload/.*\.(php|php5)?$
{
deny all;
}Apache 的 .htaccess 文件配置示例：
RewriteRule upload/(.*).(php)$ – [F]特别注意：上面的代码必须加在 PHP 引用配置的上方才有效（如 nginx 的 PHP 引用配置 include enable-php-**.conf;）
默认 Linux 系统是大小写敏感的，所以规则中的正则表达式无须忽略大小写（但必须与实际的目录或文件名大小写一致），因为 MIME 类型中设置的是小写的 .php，那么类似大写的 .PHP 文件是不被 php-fpm 解释的，结果是被当作普通文本返回到客户端。
提问：有些目录需要设置为可写入，但里面还有正常的 php 文件，禁止执行会有问题吗？（例如 Discuz! 的 config 目录，ThinkPHP 的 Runtime 目录）
解答：以 Discuz! 为例，config 下面虽然有 config_*.php 等配置文件，但这些文件并非直接供客户端浏览，而是被其它 .php 文件引用（include 方式、IO 方式等），当 config 目录禁止执行 PHP 后并不会对它们造成影响。
我们在开发程序的过程中应避免在允许写入的目录下放置直接供客户端浏览的 .php 文件。
二、程序上传的用户与执行 PHP 的用户相同（例如程序代码通过 FTP 上传，且和 PHP 一样，都使用 www 用户）
常见于虚拟空间。这种情况下，通过 PHP 上传的文件可以保存到该网站下面的任何目录下（甚至是网站目录之外，即传说中的跨站），原因大家都懂，默认 755 中第一个是“7”，即所有者拥有写入权限。
因此，除了做到上述设置，我们必须严格控制客户端上传文件的保存路径，做到以下几点：
必须更改客户端上传的文件名，而非直接使用原文件名；
不得从客户端文件名获取扩展名，或者只控制允许的后缀名。
最可靠的文件类型判别方式是分析文件签名，参考：文件签名表，以防篡改后缀名欺骗。
举个早期的栗子：上传文件名为 abc.asp;.jpg，未改文件名保存到服务器，浏览器直接访问该文件，IIS 6 当作 abc.asp 来解析。
本文不定时更新！
A： MySQL 执行 SHOW FULL PROCESSLIST
Q： 查看连接数和慢查询，适用于 MySQL 数据库无法连接 1040
A： iftop -i eth0
Q： 查看占用带宽的IP。不显示已知IP段：iftop -i eth0 -F ip/24
A： goaccess -f xxx.log
Q： 实时分析网站日志，查看请求最多的IP
A： net.xoyozo.weblog 日志分析工具
Q： 自制的 Web 日志分析工具，可按多种方式排序，纠出可疑访问
A： 重启 web 服务器
Q： 有时候能解决 CPU 和内存消耗的问题，如果一会儿又升高，则需要找另外的原因
Q： 500 服务器内部错误
502 Bad Gateway
504 Gateway Time-out
A： 查看 php 日志，可能的路径：/usr/local/php/var/log/php-fpm.log
Q： RDS MySQL IOPS 使用率高的原因和处理
A： 根据时间点查看慢查询
Q： Discuz! 论坛界面错乱、表情不显示、模块缺失、登录失败、发帖失败等等
A： 进入管理中心 - 工具 - 更新缓存，能解决大部分问题
Q： Discuz! 浏览帖子提示“没有找到帖子”
A： 进入数据库，修复表 pre_forum_post 或分表
Q： CPU 100% 或内存 100%，负载100+
A： 原因有很多，以下是一些建议：
Windows 在任务管理器中查看进程
当前是否有正常的大流量访问（譬如民生类论坛的某个帖子突然火了）特别是重启无效的情况
对比网站日志大小可大致确定哪个网站被大量恶意请求。
观察：命令 top
排查：通过关闭网站来确定是某网站的问题，通过关闭功能确定是某功能的问题，如果 nginx 崩溃请参下条
案例：通过修改 mobcent 文件夹名确定是安米的文件被疯狂请求导致的，更新插件和 mobcent 包解决问题。
如果都是正常访问，top 看到很多 php-fpm，而且个个占用 CPU 还不小，那么根据服务器硬件配置来修改 php 的并发量，如宝塔面板在 php 设置 - 性能调整 页，300 并发方案的推荐配置是：
max_children：300
start_servers：30
min_spare_servers：30
max_spare_servers：180另外，memcached 或 redis 的配置也可以进行相应的修改。
另一个案例是 kswapd0 进程占满 CPU，原因是内存不足导致 swap 分区与内存频繁交换数据。同样调整 php 的设置即可。
也可以通过 iftop 来查询占用带宽较多的 IP 并封禁（出方向），如果 CPU 能降下来，那这个 IP 就是罪魁祸首。
Q： 阿里云 ECS 的 CPU 突然达到 100%，并持续到次日 0:00 左右
A： 可能 ECS 是 t5 规格，受 CPU 积分制度限制，积分耗尽时 CPU 不工作。解决方法是更换其它规格产品或升配。
Q： ASP.NET 所在服务器 CPU 突然达到 50% 或 100%，并持续
A： 首先确定哪个网站，再依次排查网站各功能。可能是 HttpWebRequest 请求远程数据时长时间未返回结果导致的程序阻塞。
Q： nginx 服务停止
A： 查看 nginx 日志
WDCP 路径：/www/wdlinux/nginx-1.0.15/logs/error.log
Q： 公网出带宽 100%，其它指标正常
A： Windows 在任务管理器-性能-资源监视器-网络 查看占用带宽的进程PID，然后在任务管理器-详细信息中的找到对应的用户（如果为每个网站分别创建了用户，就能知道是哪个网站占用了带宽）；如果是被 PID 为 4 的 System 占用大部分带宽，也可以尝试重启 IIS 来解决。
CentOS 使用 nethogs 查看占用带宽的进程PID和USER，如果为每个网站分别创建了用户，就能知道是哪个网站占用了带宽，否则只能一个个关闭网站来判断，不知道大家有没有好的方法？当然还可以直接用 iftop 命令查看占用带宽的 IP。另外，查看每个网站在那个时间段的日志文件的大小也能大概看出是哪个网站被采集了。
A： Linux 显示每个用户会话的登入和登出信息
utmpdump /var/log/wtmp
参考：http://www.tulaoshi.com/n/20160331/2050641.html
Q： RDS 的 CPU 100%
A： 如果是突然持续占满（同时伴随 ECS 资源使用率下降，页面出现 502），很大可能是受攻击（或社交网站推送突发事件等），查看“慢查询”，添加相关索引；如果是 Discuz! 论坛，可尝试修复优化表 pre_common_session。
如果是数日缓步上升，或新项目上线，考虑 SQL 慢查询，思路：MySQL / SQL Server。
MySQL：SHOW FULL PROCESSLIST
SQL Server：sp_who
Q： php 网站的服务器，内存在数天内缓慢上升
A： 大概是 php-fpm 占用过多，或进程数太多
更改 php 的配置（如 max_spare_servers），执行：service php-fpm reload
Q： 进程 cloudfs 占用内存过多
A： 参：https://xoyozo.net/Blog/Details/cloudfs-cache
Q： RDS 磁盘占用过大
A： 参：https://xoyozo.net/Blog/Details/how-to-use-rds
Q： ECS 受到 DDoS 攻击怎么办？
A： 参：https://xoyozo.net/Blog/Details/aliyun-ddos-without-bgp
Q： 如果 ECS 和 RDS 各项指标都没有异常，但网页打开慢或打不开，TTFB 时间很长，是什么原因？
A： 数据库有坏表，尝试优化/修复表（慢 SQL 日志中锁等待时间较长的表？），或主备切换。
论坛使用阿里云的 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 分钟都会重现一次风险。
当然这个问题可以通过添加索引来解决。
对于大型站点，庞大的主题和帖子数据，分表放到一个主题表和一个帖子表中，已经成为影响性能的一个因素。因此，急需进行分表操作来避免 MySQL 对于大数据表的频繁操作。
1、后台分表
Disucz! X2 后台重新调整了分表的机制，使得分表效率和后期站点性能得到提升。具体分表设置在 后台 -> 站长 -> 主题分表（帖子分表）。
1）主题分表
主题分表分为两种类型，一种为主表，一种为存档表。主表只有一个，存档表可以有多个。我们进行分表操作，首先进行创建存档表的操作，然后进行主题移动，将指定条件的主题移动到存档表中。
a、创建存档表
打开 source/admincp/admincp_threadsplit.php 文件，找到创建存档表的条件分支
- elseif($operation == 'addnewtable')
复制代码
首先获取当前最大的主题表 id ，然后根据 forum_thread 的建表语句，生成新的存档表（id + 1），最后更新缓存。
b、主题移动
存档表建好后，下一步就是将主题移动到这个存档表中。在选择主题的时候，可以根据提供的搜索条件，特别是“更多选项”中的搜索条件，来转移符合条件的主题。这里主要是一个搜索的过程，转移数据的过程使用 REPLACE INTO … SELECT...FROM... 语句，比较简单。
2）帖子分表
帖子分表也是要分成两步，第一步先创建帖子分表，第二步转移数据。
打开 source/admincp/admincp_postsplit.php 文件，找到帖子分表的条件分支
- elseif($operation == 'split')
复制代码
如果是对主表进行分表操作，主表必须要大于400M，见下面的条件判断
- if($status && ((!$tableid && $status['Data_length'] > 400 * 1048576) || ($tableid && $status['Data_length'])))
复制代码
在站长提交分表表单后，程序会先根据 getmaxposttableid 函数获取当前帖子表最大的 id ，然后根据已有的帖子表结构，创建新分表，并更新缓存等信息。创建成功后，开始转移数据的操作。找到条件分支
- elseif($operation == 'movepost')
复制代码
，开始转移数据的操作。当从主表中转移数据时，是根据主题表中最后回复时间正序排列的主题 tid 来获取帖子数据的。
- $query = DB::query("SELECT tid FROM ".DB::table($table)." WHERE posttableid='0' AND displayorder>='0' ORDER BY lastpost LIMIT 0, 1000");
复制代码
然后，利用 movedate 函数进行转移数据。
当从从表中转移数据时，是根据给定帖子表的 id，获取此表中first=1的帖子所属 tid，
- $query = DB::query("SELECT tid FROM ".DB::table(getposttable($fromtableid))." WHERE `first`='1' LIMIT 0, 1000")
复制代码
然后利用 movedate 函数进行转移数据。
在 movedate 函数中，根据获取到的 tid ，将属于此 tid 的帖子，利用 INSERT INTO … SELECT … FROM ...来转移数据。在此过程中，更新主题表中 posttableid 这个字段，来标识帖子的存储表。
2、主题列表页分表读取
在主题列表页，只能看到主题主表中的主题。存档表中的主题都在存档区。
在这部分的代码（source/module/forum/forum_forumdisplay.php）中，所有涉及到的主题表都以 $threadtable 这个变量代替，$threadtable 这个变量的获取，又是根据用户是否查看存档区的标识 archiveid 来判定。
- $threadtable = $_G['gp_archiveid'] && in_array($_G['gp_archiveid'], $threadtableids) ? "forum_thread_{$_G['gp_archiveid']}" : 'forum_thread';
复制代码
当用户选择非存档内容时，archiveid = 0 或者不存在，这时，直接从 forum_thread 主表来读取主题列表。当用户选择存档内容时，archiveid = 1（1 表示存档表的 id，如果查看 id 为 2 的存档表，archiveid = 2），程序会根据 archiveid 来判断从哪个存档表中去获取主题列表。
3、帖子内容页分表读取
当用户浏览帖子内容页时，程序首先利用 loadforum 函数来获取当前的主题信息。在 loadforum 函数中，
- $_G['thread'] = get_thread_by_tid($tid, '*', $addcondiction, $archiveid);
复制代码
根据提供的 tid，get_thread_by_tid 函数到主表和存档表中分表去查找，直到找到对应的主题信息。
在 source/module/forum/forum_viewthread.php 文件中，根据
- $thread = & $_G['forum_thread'];
复制代码
- $threadtable = $thread['threadtable'];
- $posttableid = $thread['posttableid'];
- $posttable = $thread['posttable'];
复制代码
这两句来判定该主题应该去哪个帖子表中去获取帖子内容列表。
4、发新主题
发表新主题时，直接往主题主表中插入数据，对应的 posttableid = 0。然后，当插入帖子数据时，通过 insertpost 函数将数据插入帖子表中。
在 insertpost 函数中，会先去判断所属主题的 posttableid 值，得到目标帖子表，然后再往该帖子表中插入帖子数据。
5、发新回复
只有在主表的主题才能回复，因此，直接根据传递的tid去获取目标帖子表，然后插入数据。这个跟发新主题时，插入帖子内容过程相同。
6、编辑帖子
同样，只有在主表中的主题的帖子才能被编辑，因此，主题都在 forum_thread 表中。需要获取的是该主题的帖子在哪个帖子表中。打开 source/include/post/post_editpost.php 文件，找到
- $posttable = getposttablebytid($_G['tid']);
复制代码
程序在开始，通过这条语句来获取目标帖子表。在 getposttablebytid 函数中，程序根据 tid ，逐个主题表进行查找，找到对应的主题信息，获取目标帖子表，然后指向后续的编辑帖子操作。
8、取消存档
存在存档区的主题，如果想取消存档，可以通过页面底部的“取消存档”来执行。
打开 source/include/topicadmin/topicadmin_restore.php 文件，可以看到取消存档，实际上仅是将放在存档表中的主题移动到了主表中。同样，存档表的获取还是通过 archiveid 这个参数来决定的。
- $threadtable = $archiveid ? "forum_thread_$archiveid" : 'forum_thread';
复制代码
从这可以看出，存档的概念仅限于主题，帖子无所谓存档的概念。