制作类似下图中的拖拽排序功能：

1. 首先数据库该表中添加字段 sort，类型为 double（MySQL 中为 double(0, 0)）。

2. 页面输出绑定数据（以 ASP.NET MVC 控制器为例）：

public ActionResult EditSort()
{
    if (!zConsole.Logined) { return RedirectToAction("", "SignIn", new { redirect = Request.Url.OriginalString }); }

    db_auto2018Entities db = new db_auto2018Entities();

    return View(db.dt_dealer.Where(c => c.enabled).OrderBy(c => c.sort));
}

这里可以加条件列出，即示例中 enabled == true 的数据。

3. 前台页面引用 jQuery 和 jQuery UI。

4. 使用 <ul /> 列出数据：

<ul id="sortable" class="list-group gutter list-group-lg list-group-sp">
    @foreach (var d in Model)
    {
        <li class="list-group-item" draggable="true" data-id="@d.id">
            <span class="pull-left"><i class="fa fa-sort text-muted fa m-r-sm"></i> </span>
            <div class="clear">
                【id=@d.id】@d.name_full
            </div>
        </li>
    }
</ul>

5. 初始化 sortable，当拖拽结束时保存次序：

<script>
    var url_SaveSort = '@Url.Action("SaveSort")';
</script>
<script>
    $("#sortable").sortable({
        stop: function (event, ui) {
            // console.log('index: ' + $(ui.item).index())
            // console.log('id: ' + $(ui.item).data('id'))
            // console.log('prev_id: ' + $(ui.item).prev().data('id'))
            $.post(url_SaveSort, {
                id: $(ui.item).data('id'),
                prev_id: $(ui.item).prev().data('id')
            }, function (json) {
                if (json.result.success) {
                    // window.location.reload();
                } else {
                    toastr["error"](json.result.info);
                }
            }, 'json');
        }
    });
    $("#sortable").disableSelection();
</script>

这里回传到服务端的参数为：当前项的 id 值、拖拽后其前面一项的 prev_id 值（若移至首项则 prev_id 为 undefined）。

不使用 $(ui.item).index() 是因为，在有筛选条件的结果集中排序时，使用该索引值配合 LINQ 的 .Skip 会引起取值错误。

6. 控制器接收并保存至数据库：

[HttpPost]
public ActionResult SaveSort(int id, int? prev_id)
{
    if (!zConsole.Logined)
    {
        return Json(new { result = new { success = false, msg = "请登录后重试！" } }, JsonRequestBehavior.AllowGet);
    }

    db_auto2018Entities db = new db_auto2018Entities();

    dt_dealer d = db.dt_dealer.Find(id);

    // 拖拽后其前项 sort 值（若无则 null）（此处不需要加 enabled 等筛选条件）
    double? prev_sort = prev_id.HasValue
        ? db.dt_dealer.Where(c => c.id == prev_id).Select(c => c.sort).Single()
        : null as double?;

    // 拖拽后其后项 sort 值（若无前项则取首项作为后项）（必须强制转化为 double?，否则无后项时会返回 0，导致逻辑错误）
    double? next_sort = prev_id.HasValue
        ? db.dt_dealer.Where(c => c.sort > prev_sort && c.id != id).OrderBy(c => c.sort).Select(c => (double?)c.sort).FirstOrDefault()
        : db.dt_dealer.Where(c => c.id != id).OrderBy(c => c.sort).Select(c => (double?)c.sort).FirstOrDefault();

    if (prev_sort.HasValue && next_sort.HasValue)
    {
        d.sort = (prev_sort.Value + next_sort.Value) / 2;
    }
    if (prev_sort == null && next_sort.HasValue)
    {
        d.sort = next_sort.Value - 1;
    }
    if (prev_sort.HasValue && next_sort == null)
    {
        d.sort = prev_sort.Value + 1;
    }

    db.SaveChanges();

    return Json(new { item = new { id = d.id }, result = new { success = true } });
}

需要注意的是，当往数据库添加新项时，必须将 sort 值设置为已存在的最大 sort 值 +1 或最小 sort 值 -1。

var d = new dt_dealer
{
    name_full = "新建项",
    sort = (db.dt_dealer.Max(c => (double?)c.sort) ?? 0) + 1,
};

最近，空心图标和实心图标的讨论变得激烈起来，有言论指出空心图标在视觉上比实心图标看起来更复杂，更容易让用户差生疲劳感和倦怠感。对此，设计师们都各抒己见，一部分人表示赞同这种说法，而另一部分人则表示这样的言论将问题过分了放大化了，并且在证据方面有所欠缺。

图标也可以理解为是网站中的一种指引，是每个新用户都会涉及到的元素，所以无论空心或实心，一个能够令人一目了然，并且记忆深刻的图标才是用户真正喜欢的图标。

以下是小编搜寻的一些空心或实心的图标案例，看看你更倾心于哪一款呢？

1.模糊背景上覆盖着由简单线条、字体和单一的颜色组成的空心图标，这会让整个界面看起来很优雅。不仅如此，这种简易的设计手法也让设计师轻松不少，在效果和操作上都令大家很满意。

2.纯色的背景似乎搭配任何元素都能达到令人意想不到的效果，下面这个案例也不例外。正红色与白色之间的经典配搭，加以可爱的造型，成就了一个俏皮的实心图标设计。界面底部的实心按钮与幽灵按钮也与图标区域前后呼应。

3.APP底部的图标随着用户的任意切换，在空心和实心之间自由转变。实心的图标相比较空心的而言，给人一种更突出和明显的视觉效果，让用户更容易的抓到重点。而主内容左边的卡通小图案同时采用了空心的设置，尽显极简主义。

4.Line的界面似乎代表了大多数APP的图标设计方式。头部和底部的图标选用两种颜色的实心设计，下拉菜单部分使用空心图标。这样的设计虽然比较大众化，但不可否认的是，这样的做法的确让整个界面看起来格外整洁。

5.幽灵按钮虽然简洁大方，但是过多的使用会另界面很单调无味，但如果使用全部实心的图标设计又会觉得很突兀。下面这个案例就想出了一个好方法。既然空心实心都不合适，那不如尝试一下让两者结合在一起吧。

6.两种色差明显的颜色搭配在一起会体现出一种自然而然的时尚感，黑色背景和亮黄色的图标元素就是很典型的例子。强烈的对比色会让空心图标看起来也像实心图标一样，具有突出重点的效果。

7.Metro风格的界面设计也能运用在APP的图标模块中，案例中将各种第三方分享平台的实心图标都用方块元素连接在一起，让原本单调的图标瞬间活跃了起来，给用户一种焕然一新的感觉。

8.传统的导航图标大多会集中在一个区域内，而SevenEleven的APP在此做了很大的突破，将4个部分分别分布在界面的上下左右，简单的界面突然有了运动场的氛围，让APP充满了生命力。

9.天气类应用的看点中总会有气候图标的一席之地，正如这个案例中所表现的，这又是一个空心与实心相结合的图标设计。

10.这也是一个纯色块与实心图标搭配的案例，这个APP的界面设计其实很普通，但正因为图标的设计让网站变得可爱起来。

图标在网页设计中算是一个小单元，但它的重要性大家都有目共睹。空心图标和实心图标在不同的环境中发挥着不同的作用，美化着网页中的小细节。

一: 执行sql语句,返回受影响的行数

在mysql里面,如果没有影响,那么返回行数为  -1 ,sqlserver 里面  还没有测试过

 (var ctx =  MyDbContext())
{
    ctx.Database.ExecuteSqlCommand("");
}

二 : Database.SqlQuery<T>   EF5执行sql查询语句 Database.SqlQuery 带返回值

这个准确的说是  IEnumerable<T> SqlQuery<T>(string sql, params object[] parameters)  ,注意返回值是 IEnumerable

这个是执行sql语句,返回你想要的类型的列表

dbMain.Database.SqlQuery<int>("select max(UserId) from tb_user_account").First();

或者假如你自己有个类别

  PersonView
{      PersonID { ; ; }      Name { ; ; }
}

那么就可以直接返回这个 PersonView类

 (var ctx =  MyDbContext())
{
    var peopleViews = ctx.SqlQuery<PersonView>("").ToList();
}

直接返回你想要的数据. 例如这里是 List<PersonView> 列表

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

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

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

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

删除主题时，会变更主题表 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 广告

mag_circle 圈子（相当于 PC 版的版块）

mag_common_applaud_(n) 点赞详情表（分表）n 与 content_id 末位一致

mag_common_attachment_(n) 附件详情表（分表）n 与 aid 末位一致

mag_common_attachment_index 附件索引表

mag_common_comment_index 评论索引表（相当于 PC 版的回复表）

mag_common_content_log 对圈子内容的操作日志（点赞、评论等）

mag_show_content 圈子内容（相当于 PC 版的主题表）

mag_user 用户表

在 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 来解析。