删除主题时，会变更主题表 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
* 仅列出部分数据表及字段
mag_ads 广告
| 名 | 类型 | 注释 |
| id | int | |
| title | varchar | 标题 |
| pic | varchar | 图片 |
| begin_time | int | 开始时间 |
| end_time | int | 结束时间 |
| link | varchar | 链接 |
| …… |
mag_circle 圈子（相当于 PC 版的版块）
| 名 | 类型 | 注释 |
| id | int | |
| name | varchar | 名称 |
| …… |
mag_common_applaud_(n) 点赞详情表（分表）n 与 content_id 末位一致
| 名 | 类型 | 注释 |
| id | int | |
| type | varchar | 类型（主题/回复/打卡等） |
| content_id | int | 内容 id，末位与表名后缀一致 |
| user_id | int | 用户 id |
| status | int | 1：点赞；0：取消点赞 |
mag_common_attachment_(n) 附件详情表（分表）n 与 aid 末位一致
| 名 | 类型 | 注释 |
| aid | int | 附件ID（末位与表名后缀一致） |
| …… |
mag_common_attachment_index 附件索引表
| 名 | 类型 | 注释 |
| id | int | 附件ID |
| user_id | int | 用户ID |
| table_id | int | 分表标志 |
| …… |
mag_common_comment_index 评论索引表（相当于 PC 版的回复表）
| 名 | 类型 | 注释 |
| id | int | 附件ID |
| content_id | int | 文章ID（mag_show_content） |
| user_id | int | 用户ID |
| content | varchar | 评论内容 |
| …… |
mag_common_content_log 对圈子内容的操作日志（点赞、评论等）
| 名 | 类型 | 注释 |
| id | int | |
| type | varchar | 用户ID |
| type_value | int | 内容ID |
| user_id | int | 用户ID |
| create_time | int | 操作时间 |
| …… |
mag_show_content 圈子内容（相当于 PC 版的主题表）
| 名 | 类型 | 注释 |
| id | int | |
| user_id | int | 用户ID |
| content | varchar | 内容 |
| pics | varchar | 以半角逗号分隔的图片（附件）id |
| …… |
mag_user 用户表
| 名 | 类型 | 注释 |
| user_id | int | 用户ID |
| name | varchar | 用户名/昵称 |
| head | varchar | 头像 |
| …… |
在 MySQL 中，int 的取值范围是 [-2147483648, 2147483647]，占用 4 个字节。
int(M) 中 M 的默认值为 11，该值不影响取值范围和占用字节，仅表示最大显示宽度。
以某 int 字段存储的记录值为 2147483647 为例：
类型为 int(1) 时，SELECT 结果为 214
类型为 int(2) 时，SELECT 结果为 2147
……
类型为 int(7) 时，SELECT 结果为 214748364
类型为 int(8) ~ int(11) 时，SELECT 结果为 2147483647测试结果跟网上的说法不同
如果添加了 zerofill 属性，当然是填充零的效果，仍以上述值为例：
类型为 int(1) 时，SELECT 结果为 214
类型为 int(2) 时，SELECT 结果为 2147
……
类型为 int(7) 时，SELECT 结果为 214748364
类型为 int(8) ~ int(10) 时，SELECT 结果为 2147483647
类型为 int(11) 时，SELECT 结果为 02147483647结论，既然 M 值不影响取值范围和占用字节，那么何必去改它呢。除非有特殊业务需求，否则很容易引起逻辑混乱，特别是当你误认为它是用来限定取值范围或节省存储空间的时候。
风险名称：系统共享配置检测
风险等级：中危
检测项说明：
检测注册表项HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\LSA\\RestrictAnonymous的值，该值控制是否允许远程操作注册表
检测项目:
远程操作注册表
建议值:
1
路径:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\RestrictAnonymous
建议:
建议禁止远程访问操作注册表，建议关闭
在网站开发过程中遇到上传图片等文件的功能，需要在服务器上设置该目录可写入，并且必须防止被上传 .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 来解析。
| 优点 | 缺点 | |
| 大白菜 | 可还原 U 盘空间 支持 UEFI | 众多山寨产品，分不清哪个是正宗老牌，说不定还是新秀更优秀 Window 10 自带防病毒软件 Window Defender 提示发现威胁 一键制作的大白菜U盘，将 iso 拷入U盘后安装的纯净系统会被捆绑安装垃圾软件 |
| 老毛桃 | 可还原 U 盘空间 支持 UEFI PE 还不错 | “ISO 模式”没什么问题，但“一键制作”的是 FAT32 格式，不支持将大于 4GB 的 ISO 镜像拷贝到 U 盘 “模拟启动”可启动老毛桃界面，但直接写入硬盘映像的 U 盘无法模拟启动 卸载时，Window 10 自带防病毒软件 Window Defender 提示发现特洛伊木马 |
| 软碟通 UltraISO | 中规中矩 写入硬盘不会自动还原 U 盘空间 | 网上找序列号激活 |
推荐！ | 开源 可同时拷入多个系统镜像文件，并支持启动时选择 可支持格式化为多种文件格式 一键制作，可升级 | 暂无 |
软碟通制作 Windows 系统安装盘过程：
下载微软官方提供的 iso 系统镜像文件
如果 U 盘容量缩水，或根本无法正常使用 U 盘，使用老毛桃还原 U 盘空间
打开 UltraISO，打开要写入 U 盘的 iso 文件
在菜单上选择：启动 - 写入硬盘映像...
选择硬盘驱动器，格式化，写入（注意：点击“写入”是按 FAT32 重新格式化的，若要制作 NTFS 文件系统的 U 盘，请先按 NTFS 格式化，然后在此界面上点击“便捷启动”-“便捷写入”）
如果 U 盘足够大，可以在 U 盘里多放几个系统镜像，双击打开另一个 iso，将所有文件和文件夹复制到 U 盘上新建的目录中。这样下次需要安装什么系统时，只要把对应的系统的文件放到 U 盘根目录，其它系统移到二级目录中即可。当然还可以往里面存放一些常用软件。
另外最好常备一个带有 PE 系统的启动盘，在旧电脑上安装旧系统时经常会用到。
如果在分区那步无法删除或创建分区（提示动态卷什么的），在确认放弃磁盘中的文件的前提下，可以使用 Shift + F10 调出命令行，键入 diskpart，列出磁盘（list disk），选择磁盘（select disk 0），清除（clean），注意 U 盘启动盘也会在列表中，勿删！
重点提前看：
https://xoyozo.net/Blog/Details/MySQL-on-Windows
Connector/Net 6.10.4（暂）不支持在 Visual Studio 2015/2017 添加 ADO.NET 实体数据模型时选择 MySQL Data Provider 数据源。并且，在编译项目时会出现“违反了继承安全性规则”的异常。
只能降回 Connector/Net 6.9.10，NuGet 中将 MySql.Data 和 MySql.Data.Entity 用 6.9.10 和 6.10.4 版本皆可（除非遇到下文中提到的异常）。
重新生成或重启 VS 使之生效。
另外，MySql.Data 和 MySql.Data.Entity 6.9.10 可以配合 EnityFramework 和 EntityFramework.zh-Hans 6.1.x 和 6.2.0 使用。
MySql.Data 和 MySql.Data.Entity 6.9.9 在创建/更新实体模型向导中会出现闪退，更换为 6.9.10 试试。
或重新安装 Connector/NET 和 MySQL for Visual Studio 并重启电脑试试。
仍然闪退，参此文：https://xoyozo.net/Blog/Details/mysql-for-vs-flashback。
重要提醒，如果在添加 EF 模型时报错：
您的项目引用了最新版的实体框架；但是，找不到进行数据连接所需的与此版本兼容的实体框架数据库提供程序。请退出向导，安装兼容提供程序，重新生成您的项目，然后再执行此操作。
那么在菜单中选择：生成 - 清理解决方案，然后直接添加数据模型。如果在添加前生成了项目（bin 目录下有相关 .dll 文件），那么将出现上述错误。
类型“MySql.Data.MySqlClient.MySqlProviderServices”违反了继承安全性规则。派生类型必须与基类型的安全可访问性匹配或者比基类型的安全可访问性低。
将 MySql.Data 和 MySql.Data.Entity 从 6.10.4 退回 6.9.10 版本即可。
以上问题出现在：
VS 15.4.*
VS 15.4.4
VS 15.4.5
----------------
VS 15.5 已经可以在 EF 向导中连接 MySQL 数据库（Connector/Net 6.10.4），但 MySql.Data.Entity 6.10.4 编译仍然出现“违反了继承安全性规则”。另：MySQL 官网下架了 Connector/Net 6.10.4，退回提供 6.9.10 版本。
2017-12-9 发布的 Connector/Net 6.10.5 仍然存在无法在 EF 向导中连接 MySQL 数据源的问题。
服务器上安装 Connector/Net 6.10.4 没有任何问题。
更新 .edmx 文件时若提示：
生成模型时出现意外错误。有关详细信息，请参阅输出窗口。异常消息:“StrongTypingException: 表“TableDetails”中列“IsPrimaryKey”的值为 DBNull。”。
可以通过以下方法来解决：
1，控制面板中打开“服务”（或执行命令 services.msc），重新启动“MySQL57”
2，在 MySQL 中执行：
use <<database name>>;
set global optimizer_switch='derived_merge=OFF';如果提示“1227 - Access denied; you need (at least one of) the SUPER privilege(s) for this operation”，请使用超级用户进行操作。
3，搞定，试试更新 .edmx 吧。
这个简单的技巧用来解决使固定表头(thead)和滚动表体 (tbody) 的问题。这使得数据表更易于浏览。当用户滚动表格时，固定表头为用户所注意的列提供了上下文。看下面图示你就明白了：
默认情况下，overflow 属性不适用于表格分组元素 thead, tbody , tfoot。你可以在下面的示例中看到：
为了使其工作，
第一步是：设置 tbody 为 display:block ，以便我们可以应用 height 和 overflow 属性。
下一步将是：设置thead 中的 tr元素设置为 display:block。
所以最终的CSS会是：
.fixed_header tbody{
display:block;
overflow:auto;
height:200px;
width:100%;
}
.fixed_header thead tr{
display:block;
}这样，创建表格非常简单而且富有语义，并且没有依赖 JavaScript 。
经常会看到这样似错非错的提示：
当前上下文中不存在名称"__o"
The name '__o' does not exist in the current context
实际上，我没有定义任何名为 __o 的变量。
发生这种情况的原因可能是使用了类似如下的代码：
<% if(true) { %>
<%= 1 %>
<% } %>
<%= 2 %>为了在设计界面的 <%= %> 代码块中提供智能感知，ASP.NET（VB 或 C#）会自动生成一个名为“__o”的临时变量，这在页面编译器看到第一个 <%= %> 块时就完成了。但是在这里，<%= %> 块在 if 中出现，所以当关闭 if 后再使用 <%= %> 时，变量超出了定义的范围。
if (true)
{
object @__o;
@__o = 1;
}
@__o = 2;解决方法：在页面的早期添加一个虚表达式。例如：<%= "" %>。这将不会呈现任何内容，并且它将确保在任何潜在的 if（或其他范围界定）语句之前，在 Render 方法中将 __o 声明为顶级。
当然还有一种治标不治本的方法就是隐藏这些错误提示（这并不影响程序正常运行）：
点击错误列表面板左上角的过滤器按钮，CS0103，其中包含错误代码：当前上下文中不存在名称"__o"，这些错误将不再显示，您仍然可以有其他 IntelliSense 错误和警告。