“/”应用程序中的服务器错误。

---

The host xxx does not support SSL connections.

说明: 执行当前 Web 请求期间，出现未经处理的异常。请检查堆栈跟踪信息，以了解有关该错误以及代码中导致错误的出处的详细信息。 

异常详细信息: MySql.Data.MySqlClient.MySqlException: The host xxx does not support SSL connections.

在 Web.config  的 connectionStrings 节点找到相关数据库连接，在 connectionString 中增加属性值：SslMode=none

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

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

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

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

ASP.NET MVC 项目发布到 IIS 上，出现服务器错误“403 - 禁止访问：访问被拒绝”，排除权限设置问题后，原因在于 MVC 的 URL 通常没有扩展名，IIS 并未将其交由 ASP.NET 托管处理。

经过各种找资料，各种尝试后，最终确定：项目本身没有问题，本地运行正常，发布到另一台服务器上正常。

删除服务器 IIS 上的该网站和应用程序池，重新创建网站，恢复正常。原因未知。

在 Global.asax 的 Application_Start() 方法中添加以下代码，作用是在应用程序启动时预先访问一遍所有动态页面，办法虽土，但很有效。

本代码适合 Web Forms 项目，不适合 MVC 项目；修改代码中的 domain 值为真实的网站域名

代码整理中……

在 IIS 中设置应用程序池最长时效或永不过期，则效果更佳。

在应用程序池中选中网站对应的应用程序池，在右侧“操作”窗口中选择“正在回收...”

取消“固定间隔”框中的所有选项，确定。

实践证明，近 200 个动态页面一次性访问需要耗时近 10 分钟，发布后 10 分钟内无法正常浏览网站是同样是无法忍受的。因此更改方案为：

做一个 Winform 应用程序来定时访问这些页面，30 秒一个，一个半小时能完成一个循环，对正常浏览的影响非常小。

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

“/”应用程序中的服务器错误。

指定的参数已超出有效值的范围。
参数名: site

说明: 执行当前 Web 请求期间，出现未经处理的异常。请检查堆栈跟踪信息，以了解有关该错误以及代码中导致错误的出处的详细信息。 

异常详细信息: System.ArgumentOutOfRangeException: 指定的参数已超出有效值的范围。
参数名: site

解决方法：安装 IIS

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

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

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

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

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

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

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

注：

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

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

这个简单的技巧用来解决使固定表头(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 。

1. 下载 Senparc 官方 Sample

   
   

2. 打开：\WeiXinMPSDK-master\src\Senparc.Weixin.MP.Sample\Senparc.Weixin.MP.Sample.sln

   
   

3. 工具 - NuGet 包管理器 - 管理解决方案的 NuGet 程序包 - 更新

   选择所有的包（Microsoft.Net.Http 无法更新，暂不勾选），更新

   Microsoft.Net.Http 是个老顽固，无法更新也无法卸载，原因是它的语言包 Microsoft.Net.Http.zh-Hans 无法安装。我们切换到“已安装”选项卡，搜索“Microsoft.Net.Http”，选中 Microsoft.Net.Http.zh-Hans 并卸载它，现在我们可以更新 Microsoft.Net.Http 了。

   
   

4. 【可能】运行报错：

   “/”应用程序中的服务器错误。

   ---

   配置错误

   说明: 在处理向该请求提供服务所需的配置文件时出错。请检查下面的特定错误详细信息并适当地修改配置文件。 
   
   分析器错误消息: 创建 system.web.webPages.razor/host 的配置节处理程序时出错: 未能加载文件或程序集“System.Web.WebPages.Razor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35”或它的某一个依赖项。找到的程序集清单定义与程序集引用不匹配。 (异常来自 HRESULT:0x80131040)
   
   源错误: 
   
   

   行 4:    <configSections> 行 5:      <sectionGroup name="system.web.webPages.razor" type="System.Web.WebPages.Razor.Configuration.RazorWebSectionGroup, System.Web.WebPages.Razor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"> 行 6:        <section name="host" type="System.Web.WebPages.Razor.Configuration.HostSection, System.Web.WebPages.Razor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" /> 行 7:        <section name="pages" type="System.Web.WebPages.Razor.Configuration.RazorPagesSection, System.Web.WebPages.Razor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" /> 行 8:      </sectionGroup>

   
   源文件: E:\WeiXinMPSDK-master\src\Senparc.Weixin.MP.Sample\Senparc.Weixin.MP.Sample\views\web.config    行: 6 
   

   
   

   展开 Senparc.Weixin.MP.Sample 引用，查看 System.Web.Razor 的属性，复制版本号。打开 \views\web.config，修改 System.Web.WebPages.Razor 的 Version（有 3 处）。

   
   

5. 对于小型开发项目来说，我习惯将所有代码放在同一个项目（Project）中来，所以做了以下处理：（盛派官方分离这些代码是为了同时供 MVC 和 WebForms 重用）

   在 Senparc.Weixin.MP.Sample 中添加文件夹 CommonService，将 Senparc.Weixin.MP.Sample.CommonService 项目中的文件夹和文件（.config 除外）拖到 CommonService 文件夹中。

   卸载 Senparc.Weixin.MP.Sample.CommonService 项目并删除引用。

   
   

6. 在解决方案的 Libraries 文件夹中，我们看到 Sample 项目了以下功能模块，这些就是 Senparc.Weixin 的源代码，如果不需要修改，可以卸载它们改为使用从 NuGet 获取，以便随时更新到最新版本：

   Senparc.WebSocket

   Senparc.Weixin

   Senparc.Weixin.MP

   Senparc.Weixin.MP.MvcExtension NuGet 中对应的包名为：Senparc.Weixin.MP.MVC

   Senparc.Weixin.Open

   Senparc.Weixin.Work

   Senparc.Weixin.WxOpen

   Senparc.Weixin.Cache.Memcached

   Senparc.Weixin.Cache.Redis
   

   卸载这些项目，并在 NuGet 中安装这些模块（搜索“Senparc.Weixin”第一页都在了，认准作者 Jeffrey Su）

   单元测试项目中的引用也按需更换，当然也可以卸载这些单元测试项目（视情况保留 Senparc.Weixin.MP.Sample.Tests） 。

   
   

7. 【可能】运行报错

   
   

   HTTP Error 500.19 - Internal Server Error

   无法访问请求的页面，因为该页的相关配置数据无效。

   配置源：

   134:     </sessionState>

   135:   <sessionState customProvider="Memcached" mode="Custom">

   136: <providers>

   
   

   可以在 Global.asax 的 RegisterWeixinCache() 中修改 Memcached 配置。

   或者打开 Web.config，找到 Memcached 所在的 sessionState 标签，注释掉，这样程序自动使用上方的 InProc（应用进程内）。

   如果开启了 ASP.NET State Service 服务，那么建议改用 StateServer，与 Custom 一样需要序列化，方便日后改用 Memcached 或 Redis。

   
   

8. 再次更新 NuGet，否则会提示无法加载 Enyim.Caching 的错误（报错行：MemcachedObjectCacheStrategy.RegisterServerList(memcachedConfig);）。

   
   

9. 接下来，进入微信公众平台，在左侧 开发 - 基本配置 中设置相关参数（填写“服务器地址(URL)”如“https://weixin.xoyozo.net/weixin/”），打开 Sample 项目中的 Web.config，配置我们的公众号参数。

   
   

10. 将项目发布到服务器上，尝试向公众号发送消息吧。

    
    

11. 单元测试

    设置单元测试中的公众号配置项：打开 Senparc.Weixin.MP.Test/CommonAPIs/CommonApiTest.cs，在 AppConfig 方法中可以看到支持两种配置方式，在 Senparc.Weixin.MP.Test/Config/test.config 配置文件中配置，或直接在 CommonApiTest.cs 文件中配置，前者格式如下，后者建议只在个人测试项目中使用。

    <Config>
      <AppId>YourAppId</AppId>
      <Secret>YourSecret</Secret>
      <MchId>YourMchId</MchId>
      <TenPayKey>YourTenPayKey</TenPayKey>
      <TenPayCertPath>YourTenPayCertPath</TenPayCertPath>
      <!-- 小程序 -->
      <WxOpenAppId>YourOpenAppId</WxOpenAppId>
      <WxOpenSecret>YourWxOpenSecret</WxOpenSecret>
    </Config>

    另外，将 _testOpenId 值改为自己的微信号在本公众号上的 openid。

    
    

12. 微信网页授权（OAuth2）

    打开 OAuth2Controller 控制器，将“Index”Action 中的盛派的网址（有 2 处）改成：

    Request.Url.Scheme + "://" + Request.Url.Authority + "/Oauth2/……

    
    

13. 未完待续……
    

新建项目

使用 VS2017 / VS2015 新建项目 - ASP.NET Web 应用程序 - MVC - 个人身份验证

添加模型

右击 Models 文件夹，添加类 Movie

using System;
using System.Data.Entity;

namespace MvcMovie.Models
{
    public class Movie
    {
        public int ID { get; set; }
        public string Title { get; set; }
        public DateTime ReleaseDate { get; set; }
        public string Genre { get; set; }
        public decimal Price { get; set; }
    }

    public class MovieDBContext : DbContext
    {
        public DbSet<Movie> Movies { get; set; }
    }
}

Movie 类表示一部电影，一个对象实例对应数据库中一行，每个属性对应表中一列。

MovieDBContext 代表 EF 数据库上下文，处理抓取、存储、更新。

创建连接字符串和使用 SQL Server 

打开 Web.config

在 <configuration /> 中的 <connectionStrings /> 中添加

<add name="MovieDBContext" connectionString="Data Source=(LocalDb)\MSSQLLocalDB;AttachDbFilename=|DataDirectory|\Movies.mdf;Initial Catalog=Movies;Integrated Security=True"
      providerName="System.Data.SqlClient" />

name 必须与 DbContext 类的名称匹配（MovieDBContext）

这步将会把数据库文件 Movies.mdf 创建到 App_Data 文件夹中，你也可以使用其它 SQL Server 数据库的连接字符串，简单的方法是：

在“服务器资源管理器”中添加连接

从右击属性中获取连接字符串

从控制器访问模型的数据

右击 Controllers 文件夹添加控制器，选择 包含视图的 MVC 5 控制器(使用 Entity Framework)

模型类：Movie (MvcMovie.Models)

数据上下文类：MovieDBContext (MvcMovie.Models)

F5 运行，访问 /Movies 可添加、查看、编辑、删除影片

添加新字段

设置模型更改的 Code First 迁移

在程序包管理器控制台窗口中，在 PM> 提示符下输入

Enable-Migrations -ContextTypeName MvcMovie.Models.MovieDBContext

在 Migrations 文件夹中新建了 Configurations.cs，打开并在 Seed 方法中加入

context.Movies.AddOrUpdate(i => i.Title,
  new Movie
  {
    Title = "When Harry Met Sally",
    ReleaseDate = DateTime.Parse("1989-1-11"),
    Genre = "Romantic Comedy",
    Price = 7.99M
  },
  new Movie
  {
    Title = "Ghostbusters ",
    ReleaseDate = DateTime.Parse("1984-3-13"),
    Genre = "Comedy",
    Price = 8.99M
  }
);

Seed() 将在每次迁移（PM>update-database）后被调用执行，AddOrUpdate 将执行 upsert 操作（有则 update，无则 insert）

AddOrUpdate 的第一个参数指定用于检查行是否已存在的属性

如果该属性值不唯，则出现异常

序列包含多个元素

创建迁移命令：

PM>add-migration Initial

名称“Initial”是任意的

执行迁移：

PM>update-database

F5 运行将显示种子数据

向 Movie 模型添加 Rating 属性

向 Movie 类添加属性，生成

public string Rating { get; set; }

向 Create 和 Edit Action 方法的 Bind 属性添加 Rating

更改各视图支持新的 Rating 属性

此时 F5 运行将提示

System.InvalidOperationException:“支持“MovieDBContext”上下文的模型已在数据库创建后发生更改。请考虑使用 Code First 迁移更新数据库(http://go.microsoft.com/fwlink/?LinkId=238269)。”

要解决错误除了手动往数据库中添加 Rating 字段外可以利用 Code First 迁移：

更新 Migrations\Configuration.cs 给每个 Movie 对象添加一个 Rating 字段

PM>add-migration Rating

名称 Rating 是任意的

创建了 DbMigration 的派生类 Rating，可以看到添加新列的代码

PM>update-database

数据库自动完成了对新字段的添加，当然 update-database 也会把种子数据还原。

参考

Getting Started with ASP.NET MVC 5