statistic插件
 
 
 
在IDEA上下载不成功可以将这个包复制到idea的plugin中，重启idea就可以了
 
链接：https://pan.baidu.com/s/1uKtlM11gktNYUdpAPRAW5w 密码：rvxx
 
安装成功以后查看行数
 
如下图安装成功点击右下角的statistic，发现没有内容，然后再点击截图中的refresh就可以查看了。
 
 
 

原创作品，转载请注明出处
 
PS——本来是公司制定的行政任务，春节期间看书写读后感。真读完了之后受益良多，从学校出来后书真的读少了，多读书的习惯还是要捡起来。。。。。
 
 
 
读松下幸之助自传有感
 
       春节放假期间阅读了松下幸之助自传，通过这本书让我们看到松下是如何从一个小作坊一步步蜕变为庞大的松下商业帝国。总的来说，这本书给我的感触还是挺大的，从几件事情上谈一谈我的感受。
 
       九层之台，起于累土；千里之行，始于足下。万丈高楼平地起，再大的事业也是从点滴的小事做起。松下先生刚成立公司的时候只是一个生产改良的电灯插座的3人小作坊，估计谁也没想过松下能成为今天世界级的500强企业，所以不要瞧不起“小事业”，只要未来方向是对的，小事业也会变成大生意。
 
       这本书给我的第二点感受是既要意志坚定也要顺势而为。松下的小作坊刚成立之初做的是电灯插座的生意，没想到这个插座卖得不好，成立4个多月还没怎么赚钱，松下手头拮据不得不把自己和夫人的衣服送到了当铺。一般人意志稍微薄弱的估计早就掉头转向继续回去当技术员了，工作轻松拿钱又多。可松下先生没有这么干，他认为自己的工作有前途，坚持做。这是松下先生的坚持，认准是有前途的就意志坚定地做下去，看来我们做选择的时候还是要站在希望和未来的一边啊。就在小作坊半死不活的到了年关的时候意外接到了某电器商会的定做1000个电风扇底盘的订单，救活了自己的生意。如果只抱着只做插座的执念恐怕早就完蛋了，这也是现在很多创业者应该注意的，只要大方向不变，活下去才是首先要考虑的这就是顺势而为。
 
       第三个感触是松下先生对商品定价的看法：松下先生对某些公司为了拓展销路所采取的手段——不论成本多少，以比成本低的价格打倒同业，然后再提高价格，以便垄断市场利益——感到非常愤怒。像这样的干法只是搅乱业界，妨害社会健全发展，根本不是正确的生财之道。因此，松下电器每次的定价，都是依照成本，加上一定的利之后才确定。松下先生认为不计成本的价格战会造成行业的恶性竞争不利于行业的健康发展，在几次经销商要求降价的情况下说服众人坚持合理的价格卖出。避免打价格战引发恶性竞争，当下虽然还能看到，但已经成为众多行业的共识，松下先生能顶住压力坚持自己的看法实属不易。这也是一种正确的商品观，一分价钱一分货，好的商品一旦确立合适的价格在成本没有降低之前就不要轻易的降价。
 
       第四个是松下造收音机的故事，当时的收音机故障率不断，作为行外人的松下一心要造出不出故障的收音机，这在当时的行业内的有经验的人认为是不可能的事。可就是凭着一定要做出来的信念，松下不仅造出了故障率极低的收音机而且一帮外行人三个月造出的产品还赢得了当时的收音机比赛。这件事让我从新审视“经验”这两个字，有时候经验是好的能帮助你解决难题，可是当你否定一件事，认为它不可能实现的时候要小心是不是你的经验阻碍了你的想象，限制了你的手脚。
 
       最后一个让我有感触的地方是为了应对经济不景气产品滞销很多企业不得不裁员，松下先生却采取了生产额减半但员工一个也不许解雇，工厂勤务时间减半，员工要全力销售库存产品，这样一来，由于员工的倾力推销，不但没有滞销，反倒造成生产量不够销售的现象，创下公司历年来最大的销售额，解决了公司的危机。转变思路这一点让我尤为佩服，值得当下处于不景气时期的企业家们参考。
 
       另外松下先生对紧缩政策的看法半个世纪后依然值得我们学习：一般的社会人士，都跟随着滨口内阁的紧缩政策，停止了脚步，以致经济愈来愈萧条、困窘情况愈来愈糟糕。政府各机关都把文明的宠儿——汽车停用，以身作则，为民表率。劝导社会大众配合政府的紧缩政策，一切节约，共度难关。 可是，大企业、工商大财团跟随政府实行紧缩政策，不但不能解决经济不景气的危机，反倒造成经济萧条，收支愈来愈不平衡，也促使失业率增高，导致社会的不稳定。大家都不盖房子，木匠就没有工作做，只好游手好闲过 日子，成为政府“紧缩政策”下的牺牲品。由于政府的紧缩政策，造成本来 有工作的人失业了，刚从学校毕业的学生也找不到职业。如此恶性循环，人 心便愈加惶恐，社会也跟着动荡不安。松下幸之助先生确认为，政府的“紧缩政策”，才 是经济不景气的罪魁。“我对这种政策感到很遗憾。我很怀疑，萧条景象若持 续下去，日本的产业能够进展吗？依我的常识，我认为站在指导地位的人，应在此时刻，分秒必争地为使日本繁荣而卖力才对。为了要达到繁荣的目的，应该要“活动，再活动”本来走路的地方，要改骑脚踏车；本来骑脚踏车的地方，要改开汽车，藉此提高活动效率。东西用得愈多愈好，这样才能促进新旧产品的更新循环，工业技术才会更加提升，才能消除不景气，实现繁荣日本的目标，国民才会有朝气、有干劲，国家才会富强。然而，政府所采取的紧缩政策，却造成相反的结果。”
 
       松下幸之助自传这本书让我受益良多。多读书，读好书。学习才能进步，今后要多读书，养成勤读书的习惯才行。

当辅助窗口启动完毕，我们首先需要读取游戏配置，这里以读取游戏启动路径为例，通用对话框过滤器设置，窗口创建完毕，大漠初始化，大漠全局路径设置，设置大漠字库，选择夹的使用技巧等等......
 
 
 
易语言源码：
 
.版本 2

.子程序 __启动窗口_创建完毕
.局部变量 取运行目录, 文本型

剑侠游戏路径 ＝ 读配置项 (取运行目录 () ＋ “\jxqy.ini”, “游戏路径”, “path”, 剑侠游戏路径)
.如果 (取文本长度 (剑侠游戏路径) ＞ 0)
    分组框4.可视 ＝ 假

.否则
    信息框 (“第一次运行本外挂，请在首次配置里运行一下游戏，把游戏路径写入配置项！”, 0, , )
    选择夹1.现行子夹 ＝ 1
    编辑框_游戏路径.获取焦点 ()
    _运行游戏_被单击 ()
    选择夹1.现行子夹 ＝ 0
    编辑框_账号.获取焦点 ()

.如果结束
' 初始化大漠，设置全局路径，设置字库，这里只需要一次
初始化 (1)
SetPath (取运行目录 (), 1)
SetDict (0, “一键登录字库.txt”, 1)
 
源文：易语言大漠游戏外挂一键启动读配置项
 
         511遇见易语言大漠游戏外挂一键登录

相对数据库镜像，AlwaysOn的一个重要优势就是可以将辅助数据库配置成可读模式。这极大地增强了数据库整体的伸缩性。通过将只读请求分流到辅助数据库，主副本的工作负载得到了减轻，读和写之间的冲突可以得到缓解，辅助副本的硬件资源也能得到利用。同时，通过AlwaysOn的“只读路由”功能，只读操作可以动态地被转向辅助副本。在一定程度上，可以实现对终端用户透明。利用这个功能，SQLServer可以实现工作负荷的Scale-out（由多台SQLServer同时响应客户端发来的工作负载）。对于高端应用，这的确是一个令人激动人心的新功能。
 
当然，主副本的数据和辅助副本上查询到的数据可能会存在一定程度的滞后。通常情况下，只要AlwaysOn工作正常，这个滞后时间一般都很短。当辅助数据库I/O较慢或者副本之间网络状况不佳的情况下，滞后时间可能会比较长。当辅助副本的数据移动挂起的时候，滞后时间就更长了。如果应用的读操作不能容忍任何程度的数据滞后，操作还是只能放在主副本上运行。
 
要让只读操作能“透明”地被自动转向辅助副本，必须解决下面三个问题：
 
1.      客户端要标明自己发来的操作是“只读”操作。这个判定是程序开发员在编写程序的时候，通过ApplicationIntent关键字指定的。而不是SQL Server端来判定的。
 
2.      辅助数据库要被配成可读模式。
 
3.      客户端的连接，要能够被重定向到可读辅助副本。AlwaysOn是用“只读路由”机制来实现的。
 
下面来详细介绍这几个问题。
 
ApplicationIntent关键字
 
为了支持AlwaysOn可用性组的可读辅助数据库功能，连接SQLServer 2012实例的客户端可以使用新的关键字“ApplicationIntent”来表示客户端发出请求的类型：“读/写”或是“只读”。这个关键字只能被设置为以下两个值中的一个。
 
ApplicationIntent=ReadOnly
 
ApplicationIntent=ReadWrite
 
目前支持该关键字的驱动有：
 
·        SQLNCLI11 ODBC和OLEDB
 
·        .NET Framework 4.5和4.0中System.Data.SqlClient
 
·        Microsoft JDBC Driver for SQL Server 4.0
 
设置ApplicationIntent关键字的方法取决于你使用的客户端工具。如果是一个自己开发的应用程序，就需要在连接字符串中指定这个关键字，例如：
 
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI;ApplicationIntent=ReadOnly;MultiSubnetFailover=True
 
 
 
如果是SQLServer Management Studio的话，你可以在连接属性中加入ApplicationIntent关键字。
 
                              
 
可用性副本的可读模式设定
 
你可以为每个可用性副本设置其作为主角色时的连接访问类型和其作为辅助角色时的连接访问类型。
 
在创建AlwaysOn可用性组的时候，就可以为每个副本设定其作为辅助角色的连接访问类型，在可用性组运行时也能随时对其进行更改。连接访问类型决定该辅助副本上的可用性数据库是否可以接受读操作。
 
辅助角色的连接访问类型分为3种：
 
1.      NONE：辅助数据库不接受任何类型的数据访问。
 
2.        READ_ONLY：当连接字符串中的Application Intent属性被设置成ReadOnly时，能被访问。
 
3.      ALL。任何连接都可以连接辅助数据库，但是通过这个连接，只有读请求才能够成功执行。任何尝试写数据库的请求都会失败。这个选项主要是用于那些无法使用ApplicationIntent关键字的客户端。
 
ApplicationIntent并不能保证从该连接上发出的请求都一定是读操作。它只是表示了该连接上“应当”发生的请求类型。因此无论把访问类型设置为ALL或者READ_ONLY，客户端程序都可能通过这个连接发送写请求到辅助数据库上。
 
 
 
主副本上也有两种设置，只能在可用性组创建完毕后，以通过修改可用性副本的属性来完成。主角色的连接访问类型有两种。
 
1.      ALL：主数据库同时允许读写连接和只读连接。这是主角色的默认行为。
 
2.      READ_WRITE：当连接字符串的ApplicationIntent 关键字设置为 ReadWrite 或未设置时，允许此连接。不允许连接字符串ApplicationIntent关键字设置为 ReadOnly 的连接。 
 
当主副本设置为Read_Write时，如果一个客户端连接字符串ApplicationIntent关键字设置为ReadOnly，又要指定连接主副本，那这个连接会被拒绝。这样的设计会保证主副本不被应该由辅助副本完成的应用负载所干扰。
 
只读路由
 
你有两种方法来连接可读的辅助数据库。
 
·        客户端应用可以指定辅助副本的真实实例名，直接连接到该实例上。当辅助副本的连接访问选项设置为ALL时，客户端的连接字符串不用做任何特殊设置。当辅助副本设成READONLY时，客户端需要将ApplicationIntent设置为ReadOnly。由于是直接连接辅助数据库，不会发生任何的连接重定向。
 
·        AlwaysOn有一个叫做的只读路由（Read-Only Routing）的功能。当客户端连接使用Listener的名字来访问SQL Server实例时，只读路由功能可以将来自客户端的只读请求从主副本上自动重定向到可读的辅助副本上去执行。客户端应用程序只需要确保连接的服务器名是Listener的名字，而无需去关心背后到底是哪个副本响应这个请求。这个功能可以自动分流一部分主副本的工作负载，使得主副本有更多的资源处理其他读写请求。
 
如果可用性组有多个副本的话，你无法保证只读路由始终将所有连接全部重定向到相同的只读副本上。副本的运行状态的变化，副本的路由配置发生更改等因素都可能导致客户端连接到不同的只读副本。若要确保所有只读请求都连接到相同的只读副本，请使用指定可读辅助副本的实例名的方式来进行连接，而不要依靠只读路由。
 
实现只读路由功能需要以下条件：
 
1.      客户端应用程序使用TCP协议，通过Listener连接到主副本，而非直接通过主副本的实例名。
 
2.      客户端应用程序的连接字符串中，将ApplicationIntent属性设置为了ReadOnly。
 
3.      至少有一个辅助副本被配置为可读辅助副本，且其连接访问设置必须是ALL或者READONLY。
 
4.      已经为可用性副本配置了只读路由。这包括：
 
（1）        为每个副本设置一个只读路由URL（read-only routing URL）。
 
（2）        为每个副本设置其作为主副本时的只读路由列表（read-only routing list）。
 
 
 
接下来详细介绍一下只读路由URL和只读路由列表。只读路由URL是一个如下形式的字符串：
 
'TCP://servername.domain.com:1433'
 
可以看出这个URL其实就是一个端点的形式。通常这个端点指向的就是副本本身。因此你要保证客户单可以通过URL中的服务器名和端口号来访问到这个副本。这个字符串会由主副本通过“重定向TDS”送回给客户端。
 
只读路由列表是一个表示可用性副本优先级的列表。在列表中的副本的名字都使用短名字。假设有一个包含3个副本(Node1,Node2和Node3)的可用性组。在Node1上的路由列表可能是这样的：
 
'Node3','Node2'
 
这个列表表示只读请求会先被重定向到Node3。当Node3不可用的时候，请求就会被重定向到Node2。而Node2上的列表可能会是这样的：
 
'Node3', 'Node1'
 
您必须先设置只读路由URL，然后才能配置只读路由列表。
 
以下是一段联机丛书上的示例TSQL语句，用来展示如果在两副本的可用性组上配置只读路由URL和只读路由列表。假设这两个副本分别叫Computer01和Computer02。
 
 
只读路由使用以下过程来决定将只读请求重定向到哪台辅助副本。
 
前提条件：客户端在连接字符串中指定ApplicationIntent=ReadOnly，并且用Listener来连接可用性组。（如果不符合这两个条件，只读路由将不会工作。）
 
1.      连接请求会首先被指向到主副本上。
 
2.      主副本检查目标数据库，确认该数据库属于某个可用性组。
 
3.      如果数据库属于可用性组，再检查主副本上是否配置了只读路由列表。如果没有配置只读路由列表，那么只读路由还是不会工作。
 
4.      如果发现了只读路由列表，主副本就会按照列表的顺序依次检查每个副本，直到发现第一个连接访问设置为READONLY或ALL的可用副本为止。
 
5.      主副本把发现的那个副本的只读路由URL通过TDS包发还给客户端。
 
6.      客户端读取URL后即重新将自己定向到那个只读辅助副本。
 
所以对于每个用Listener名字发出的只读连接，它会先到主副本上转一圈，拿到只读辅助副本的URL以后，再连接到真正的辅助副本上。
 
辅助数据库上可能的性能问题
 
一个可读的辅助副本可能会同时受到读操作和写操作。读操作来自于直接连接它的客户端或者通过只读路由被重定向到它的客户端。而写操作只会来自于主数据库和辅助数据库之间的数据库同步。辅助数据库只有在重做日志的时候才会发生数据更改。客户端无法直接在辅助数据库上执行数据修改操作。
 
像其他所有数据库一样，只读辅助数据库也有可能遇到性能问题。由于其工作方式的特殊性，其性能问题也有所不同：
 
1.      使用行版本控制来消除阻塞问题
 
由于存在读写同时发生的可能性，在辅助数据库上可能会发生阻塞问题。为了保障读操作的稳定运行和性能，AlwaysOn使用行版本控制来消除辅助数据库上的阻塞问题。对辅助数据库运行的所有查询都会被自动运行在快照隔离级别之下。即使你显式的为查询设置了其他事务隔离级别，情况也是如此。此外，所有锁定提示（LockHint）都将被忽略。这些都有助于消除了读写操作互相争抢锁定数据所造成的阻塞问题。
 
虽然由于快照隔离级别的原因，读操作不会在数据上占用共享锁，但是快照隔离级别会导致读操作占用Sch-S锁。Sch-S锁还是会阻塞那些在辅助数据库上重做的DDL语句。因为那些DDL语句需要占用Sch-M锁，而Sch-M锁和Sch-S锁是互斥的。
 
除了阻塞，读操作的Sch-S锁还可能造成和写操作之间的死锁问题。为了保证数据同步的完整性，AlwaysOn规定来自于数据同步（重做日志）所做的写操作永远不会被选为死锁的牺牲者，无论该写操作的代价是多小。
 
2.       系统资源的争抢
 
如果读操作比较复杂，其所带来的CPU和IO的负载也可能会影响辅助数据库上重做操作的性能。因此，如果你有一个需要长时间运行的只读操作，最好还是安排在非业务高峰时间来运行会比较好。
 
3.       索引
 
为了优化在可读辅助数据库上所执行的查询语句的性能，你需要在数据库上创建合适的索引。由于你无法在辅助数据库运行创建索引的命令，你需要在主数据上创建所需要的索引，然后让同步操作把索引给同步到辅助数据库上去。
 
4.       统计信息
 
统计信息对于查询操作的性能也有非常大的影响。正确的统计信息才能产生优化的执行计划。和索引一样，你只能在主数据上创建和维护统计信息，然后将统计信息的变更同步到辅助数据库上。当主数据上没有统计信息，或者统计信息已经很过时不再用适用于生成优化的只读操作执行计划的时候，你无法在辅助数据库上创建或更新统计信息。但是，辅助副本会在tempdb 中创建和维护辅助数据库的“临时统计信息”，用它们来替代过时的永久统计信息。一旦主数据库上的永久统计信息被更新了，辅助数据库上的永久统计信息也会被更新。这时，辅助数据库就会开始使用更新的永久统计信息，因为该信息比临时统计信息要新。
 
临时统计信息的名称会带有后缀“_readonly_database_statistic”，用于将其和主数据库上保存的永久统计信息区分开来。后缀_readonly_database_statistic 是保留关键字，在主数据库上手动创建统计信息时不能使用此后缀。只有SQL Server本身才能够创建和更新辅助数据库上的临时统计信息。但是，你可以在辅助副本的tempdb中使用DROPSTATISTICS Transact-SQL 语句删除临时统计信息。你也可以在辅助副本上查询sys.stats和sys.stats_columns 视图，来监视统计信息的状况。sys_stats 包含一个is_temporary 列，用于指示哪些统计信息是永久的，哪些统计信息是临时的。
 
因为临时统计信息保存在tempdb 中，所以重启SQL Server 服务会导致所有临时统计信息丢失。如果可用性组发生故障转移，所有辅助副本上临时统计信息都会被删除。
 
可读辅助副本会占用一部分tempdb的空间。临时统计信息，以及快照隔离级别的行版本信息都保存在辅助副本的tempdb中。因此对于辅助副本的tempdb需要进行合理的配置和优化，用以优化辅助副本的性能表现。