摘要：
要提高IP原生查询的性能,可以从以下几个方面着手:微服务架构以其灵活性、可扩展性等优势,与IP原生查询高度契合。通过以下措施,可实现二者的无缝结合:通过优化查询性能和与微服务架构的... 要提高IP原生查询的性能,可以从以下几个方面着手:
微服务架构以其灵活性、可扩展性等优势,与IP原生查询高度契合。通过以下措施,可实现二者的无缝结合:
通过优化查询性能和与微服务架构的深度融合,IP原生查询可以更好地服务于各类应用场景,为企业信息化注入新的动力。
sql语句性能如何优化？？
查询速度慢的原因很多，常见如下几种： 1、没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷) 2、I/O吞吐量小，形成了瓶颈效应。 3、没有创建计算列导致查询不优化。 4、内存不足 5、网络速度慢 6、查询出的数据量过大（可以采用多次查询，其他的方法降低数据量） 7、锁或者死锁(这也是查询慢最常见的问题，是程序设计的缺陷) 8、sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。 9、返回了不必要的行和列 10、查询语句不好，没有优化
如何进行SQL性能优化
SQL Server数据库查询速度慢的原因有很多，常见的有以下几种：1、没有索引或者没有用到索引(这是查询慢最常见的问题，是数据库设计的缺陷)2、I/O吞吐量小，形成了瓶颈效应。 3、没有创建计算列导致查询不优化。 4、内存不足5、网络速度慢6、查询出的数据量过大（可以采用多次查询，其他的方法降低数据量）7、锁或者死锁(这也是查询慢最常见的问题，是程序设计的缺陷)8、sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。 9、返回了不必要的行和列10、查询语句不好，没有优化●可以通过以下方法来优化查询 :1、把数据、日志、索引放到不同的I/O设备上，增加读取速度，以前可以将Tempdb应放在RAID0上，SQL2000不在支持。 数据量（尺寸）越大，提高I/O越重要。 2、纵向、横向分割表，减少表的尺寸(sp_spaceuse)3、升级硬件4、根据查询条件,建立索引,优化索引、优化访问方式，限制结果集的数据量。 注意填充因子要适当（最好是使用默认值0）。 索引应该尽量小，使用字节数小的列建索引好（参照索引的创建）,不要对有限的几个值的字段建单一索引如性别字段。 5、提高网速。 6、扩大服务器的内存,Windows 2000和SQL server 2000能支持4-8G的内存。 配置虚拟内存：虚拟内存大小应基于计算机上并发运行的服务进行配置。 运行 Microsoft SQL Server? 2000时，可考虑将虚拟内存大小设置为计算机中安装的物理内存的1.5倍。 如果另外安装了全文检索功能，并打算运行Microsoft搜索服务以便执行全文索引和查询，可考虑：将虚拟内存大小配置为至少是计算机中安装的物理内存的3倍。 将SQL Server max server memory服务器配置选项配置为物理内存的1.5倍（虚拟内存大小设置的一半）。 7、增加服务器CPU个数;但是必须 明白并行处理串行处理更需要资源例如内存。 使用并行还是串行程是MSSQL自动评估选择的。 单个任务分解成多个任务，就可以在处理器上运行。 例如耽搁查询 的排序、连接、扫描和GROUP BY字句同时执行，SQL SERVER根据系统的负载情况决定最优的并行等级，复杂的需要消耗大量的CPU的查询最适合并行处理。 但是更新操作UPDATE,INSERT， DELETE还不能并行处理。 8、如果是使用like进行查询的话，简单的使用index是不行的，但是全文索引，耗空间。 like a% 使用索引 like %a 不使用索引用 like %a% 查询时，查询耗时和字段值总长度成正比,所以不能用CHAR类型，而是VARCHAR。 对于字段的值很长的建全文索引。 9、DB Server 和APPLication Server 分离；OLTP和OLAP分离10、分布式分区视图可用于实现数据库服务器联合体。 联合体是一组分开管理的服务器，但它们相互协作分担系统的处理负荷。 这种通过分区数据形成数据库服务器联合体的机制能够扩大一组服务器，以支持大型的多层 Web 站点的处理需要。 有关更多信息，参见设计联合数据库服务器。 （参照SQL帮助文件分区视图）a、在实现分区视图之前，必须先水平分区表b、 在创建成员表后，在每个成员服务器上定义一个分布式分区视图，并且每个视图具有相同的名称。 这样，引用分布式分区视图名的查询可以在任何一个成员服务器上 运行。 系统操作如同每个成员服务器上都有一个原始表的复本一样，但其实每个服务器上只有一个成员表和一个分布式分区视图。 数据的位置对应用程序是透明的。 11、重建索引 DBCC REINDEX ,DBCC INDEXDEFRAG,收缩数据和日志 DBCC SHRINKDB,DBCC SHRINKFILE. 设置自动收缩日志.对于大的数据库不要设置数据库自动增长，它会降低服务器的性能。 在T-sql的写法上有很大的讲究，下面列出常见的要点：首先，DBMS处理查询计划的过程是这样的：1、 查询语句的词法、语法检查2、 将语句提交给DBMS的查询优化器3、 优化器做代数优化和存取路径的优化4、 由预编译模块生成查询规划5、 然后在合适的时间提交给系统处理执行6、 最后将执行结果返回给用户。 其次，看一下SQL SERVER的数据存放的结构：一个页面的大小为8K(8060)字节，8个页面为一个盘区，按照B树存放。
如何优化索引：提高SQL语句查询性能
查询优化的统计信息是一些对象，这些对象包含与值在表或索引视图的一列或多列中的分布有关的统计信息。 查询优化器使用这些统计信息来估计查询结果中的基数或行数。 通过这些基数估计，查询优化器可以创建高质量的查询计划。 例如，查询优化器可以使用基数估计选择索引查找运算符而不是耗费更多资源的索引扫描运算符，从而提高查询性能。 每个统计信息对象都在包含一个或多个表列的列表上创建，并且包括显示值在第一列中的分布的直方图。 在多列上的统计信息对象也存储与各列中的值的相关性有关的统计信息。 这些相关性统计信息（或密度）根据列值的不同行的数目派生。 使用数据库范围的统计信息选项自动创建统计信息选项 AUTO_CREATE_STATISTICS 和自动更新统计信息选项 AUTO_UPDATE_STATISTICS 默认为 ON，我们建议使用这一默认值来用于大多数用户数据库。 您可以使用以下 SELECT 语句来为所有用户数据库查看这些选项的当前值：[sql] view plain copySELECTname AS Name, is_auto_create_stats_on AS Auto Create Stats,is_auto_update_stats_on AS Auto Update Stats,is_read_only AS Read Only FROM database_ID > 4;查看统计统计信息DBCC SHOW_STATISTICS 显示表或索引视图的当前查询优化统计信息。 语法结构参考DBCC SHOW_STATISTICS，这里不做过多阐述。 确定何时创建统计信息 查询优化器已通过以下方式创建统计信息：1、在创建索引时，查询优化器为表或视图上的索引创建统计信息。 这些统计信息将创建在索引的键列上。 如果索引是一个筛选索引，则查询优化器将在为该筛选索引指定的行的同一子集上创建筛选统计信息。 2、在 AUTO_CREATE_STATISTICS 为 ON 时，查询优化器为查询谓词中的单列创建统计信息。 对于大多数查询，用于创建统计信息的这两个方法就可以确保高质量的查询计划；但在很少的情况下，可以通过使用 CREATE STATISTICS 语句创建附加的统计信息，改进查询计划。 这些附加的统计信息可以捕获查询优化器在为索引或单列创建统计信息时并未考虑的统计关联。 您的应用程序可能在表数据中具有附加的统计关联，如果在统计信息对象中计入这些关联，可能会令查询优化器改进查询计划。 例如，针对数据行子集的筛选统计信息或针对查询谓词列的多列统计信息可改进查询计划。 在使用 CREATE STATISTICS 语句创建统计信息时，我们建议保持 AUTO_CREATE_STATISTICS 选项为 ON，以便查询优化器继续为查询谓词列定期创建单列统计信息。 在以下任何情况适用时，考虑使用 CREATE STATISTICS 语句创建统计信息：① 数据库引擎优化顾问建议创建统计信息。 ② 查询谓词包含尚不位于相同索引中的多个相关列。 ③ 查询从数据的子集中选择数据。 ④ 查询缺少统计信息。 了解上面的基础知识，那么开始本文的重点，实际操作中怎么Using Statistics to Improve Query Performance通常情况下，设置了 AUTO_CREATE_STATISTICS 和AUTO_UPDATE_STATISTICS 的话，数据库就会自动去创建管理了，但是有时候并不尽人意。 尤其是它创建了统计信息，但是更新的不及时，导致查询执行时间很长。 这类情况最明显的一个特征就是你修改where条件的参数值，执行时间会有非常大的差异。 例如下面这个例子[sql] view plain copy--1SELECT COUNT(*) FROMa WITH (NOLOCK) , b WITH (NOLOCK) WHERE = AND = AND = AND = 2013-2-28 --2SELECT COUNT(*) FROM a WITH (NOLOCK) , b WITH (NOLOCK) WHERE = AND = AND = AND = 2013-3-31 两个表a ，b的数据量都在五六百万左右，结构上b表是联合主键(Daytime,Prodid,Siteid),a 表中这三个列是非聚集联合索引。 这是一个比较简单的内连接语句，当更改日期参数，前者只需要1s，后者需要30+；为什么会出现这样的差异呢，这里说下我的分析思路，先看执行计划差异很大（这里我就不贴图了）。 主要差异是第一个走了哈希联接，第二个是LOOP JOIN（LOOP JOIN和哈希联接的具体信息可以参考联机帮助上的说明），这两个表的数据量都比较大，所以LOOP JOIN是不合理的方案。 按照正常来说执行计划应该是一样的，我首先想到的是索引碎片，通过脚本查看两个被使用到的索引碎片率很低，排除掉这个原因，然后想到了索引统计信息，发现a表主键上一次更新统计信息的日期是在2013-03-04 ，然后调整日期参数，这个之前的查询都很快，后面的都特慢。 然后使用 UPDATE STATISTICS更新了统计信息，两个语句的执行计划都一致了，速度都正常了。 总结：对于改天查询中的一个参数或多个参数值导致查询执行时间差异很大的语句，多半是Statistics没有及时跟上，我们需要手动更新一下。 在之后我们观察这个索引的自动更新统计是否为ON，如果配置正常但是Statistics还不能及时跟上的建议建立一个job定期检查统计信息更新情况并处理。