sql数据库

T- SQL性能优化详解 http://www.cnblogs.com/weixing/p/3357519.html 故事开篇：你和你的团队经过不懈努力，终于使网站成功上线，刚开始时，注册用户较少，网站性能表现不错，但随着注册用户的增多，访问速度开始变慢，一些用户开始发来邮件表示抗议，事情变得越来越糟，为了留住用户，你开始着手调查访问变慢的原因。 　　经过紧张的调查，你发现问题出在数据库上，当应用程序尝试访问/更新数据时，数据库执行得相当慢，再次深入调查数据库后，你发现数据库表增长得很大，有些表甚至有上千万行数据，测试团队开始在生产数据库上测试，发现订单提交过程需要花5分钟时间，但在网站上线前的测试中，提交一次订单只需要2/3秒。 　　类似这种故事在世界各个角落每天都会上演，几乎每个开发人员在其开发生涯中都会遇到这种事情，我也曾多次遇到这种情况，因此我希望将我解决这种问题的经验和大家分享。 　　如果你正身处这种项目，逃避不是办法，只有勇敢地去面对现实。首先，我认为你的应用程序中一定没有写数据访问程序，我将在这个系列的文章中介绍如何编写最佳的数据访问程序，以及如何优化现有的数据访问程序。 　　 范围 　　在正式开始之前，有必要澄清一下本系列文章的写作边界，我想谈的是“事务性(OLTP)SQL Server数据库中的数据访问性能优化”，但文中介绍的这些技巧也可以用于其它数据库平台。 　

面试的时候被面试官问到sql语句的性能优化，回来百度才发现我了解的那些真的是凤毛麟角，废话不多说，上干货： 1， 对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。 2，应尽量避免在 where 子句中对字段进行 null 值判断，创建表时NULL是默认值，但大多数时候应该使用NOT NULL，或者使用一个特殊的值，如0，-1作为默 认值。 3，应尽量避免在 where 子句中使用!=或<>操作符， MySQL只有对以下操作符才使用索引：<，<=，=，>，>=，BETWEEN，IN，以及某些时候的LIKE。 4，应尽量避免在 where 子句中使用 or 来连接条件， 否则将导致引擎放弃使用索引而进行全表扫描， 可以 使用UNION合并查询： select id from t where num=10 union all select id from t where num=20 5，in 和 not in 也要慎用，否则会导致全表扫描，对于连续的数值，能用 between 就不要用 in 了：Select id from t where num between 1 and 3 6，下面的查询也将导致全表扫描：select id from t where name like ‘%abc%’ 或者select id from t

笔者对数据库了解的不是很多，最近有个需求需要整合DerBy数据库，所以需要研究了下它的ODBC编程方式。主要参考IBM官网的一篇文章，链接地址如下： 点击此处 。按照它的步骤进行操作发现，编目数据库没问题，也可以连接上，但执行sql语句会有问题。最后经过搜索资料，发现需要在db2 client端进行以下设置：DB2COMM=tcpip；DB2CODEPAGE=1208，一个是设置通信默认协议，一个是解决编码问题。再次进行ODBC 连接测试，并在DB2 CLP中运行sql语句成功返回结果。 来源： https://www.cnblogs.com/uvyifan/archive/2013/03/22/2975797.html

介绍 Yearning MYSQL 是一个SQL语句审核平台。提供查询审计，SQL审核等多种功能，支持Mysql，可以在一定程度上解决运维与开发之间的那一环，功能丰富，代码开源，安装部署容易！ 开源地址 https://gitee.com/cookieYe/Yearning 功能介绍 1、 SQL查询查询导出查询自动补全 2、 SQL审核流程化工单SQL语句检测SQL语句执行SQL回滚 3、 历史审核记录 4、 查询审计 5、 推送E-mail工单推送钉钉webhook机器人工单推送 6、 其他LDAP登陆用户权限及管理拼图式细粒度权限划分(共12项独立权限,可随意组合) 模块介绍 Dashboard dashboard主要展示Yearning各项数据包括用户数/数据源数/工单数/查询数以及其他图表，个人信息栏内用户可以修改密码/邮箱/真实姓名，同时可以查看该用户权限以及申请权限 我的工单 展示用户提交的工单信息.，对于执行失败/驳回的工单点击详细信息后可以重新修改sql并提交 对于执行成功的工单可以查看回滚语句并且快速提交SQL 工单DLL DDL相关SQL提交审核，查看表结构/索引，SQL语法高亮/自动补全 DML审核 DML相关SQL提交审核，SQL语法高亮/自动补全 查询 查询/导出数据 SQL语法高亮/自动补全 快速DML语句提交 工单审核 DDL/DML管理员审核并执行

1 、数据操作 SELECT -- 从数据库表中检索数据行和列 INSERT -- 向数据库表添加新数据行 DELETE -- 从数据库表中删除数据行 UPDATE -- 更新数据库表中的数据 2 、数据定义 CREATE TABLE -- 创建一个数据库表 DROP TABLE -- 从数据库中删除表 ALTER TABLE -- 修改数据库表结构 CREATE VIEW -- 创建一个视图 DROP VIEW -- 从数据库中删除视图 CREATE INDEX -- 为数据库表创建一个索引 DROP INDEX -- 从数据库中删除索引 CREATE PROCEDURE -- 创建一个存储过程 DROP PROCEDURE -- 从数据库中删除存储过程 CREATE TRIGGER -- 创建一个触发器 DROP TRIGGER -- 从数据库中删除触发器 CREATE SCHEMA -- 向数据库添加一个新模式 DROP SCHEMA -- 从数据库中删除一个模式 CREATE DOMAIN -- 创建一个数据值域 ALTER DOMAIN -- 改变域定义 DROP DOMAIN -- 从数据库中删除一个域 3 、数据控制 GRANT -- 授予用户访问权限 DENY -- 拒绝用户访问 REVOKE -- 解除用户访问权限 4 、事务控制 COMMIT -- 结束当前事务

重建索引是为了减少数据碎片。数据碎片会导致SQL Server进行不必要的数据读，降低SQL Server的性能。重建索引也会同时更新列统计，而如果查询所使用的列缺少或遗漏统计信息，这可能导致SQL Server内部的优化器选择比预期效率低的查询计划。 如果您重建了某张表上的聚集索引，该表上的非聚集索引也同时会被更新。 要更新索引，您可以使用Maintenance Wizard（相关内容您可以参考http://msdn.microsoft.com/en-us/library/ms180074.aspx），或在SQL Server代理（Agent）中运行如下的自定义代码来更新某个数据库中所有表上的索引： USE DatabaseName --Enter the name of the database you want to reindex DECLARE @TableName varchar(255) DECLARE TableCursor CURSOR FOR SELECT table_name FROM information_schema.tables WHERE table_type = 'base table' OPEN TableCursor FETCH NEXT FROM TableCursor INTO @TableName WHILE @@FETCH_STATUS

DBCC showcontig('Table') DBCC DBREINDEX('Table') 分析表的索引建立情况：DBCC showcontig('Table') DBCC SHOWCONTIG 正在扫描 'Table'' 表... 表: 'Table'' (53575229)；索引 ID: 1，数据库 ID: 14 已执行 TABLE 级别的扫描。 - 扫描页数................................: 228 - 扫描区数..............................: 52 - 区切换次数..............................: 225 - 每个区的平均页数........................: 4.4 - 扫描密度 [最佳计数:实际计数].......: 12.83% [29:226] - 逻辑扫描碎片 ..................: 97.37% - 区扫描碎片 ..................: 98.08% - 每页的平均可用字节数........................: 2686.3 - 平均页密度(满).....................: 66.81% 当你发现，扫描密度行，最佳计数和实际计数的比例已经严重失调，逻辑扫描碎片占了非常大的百分比

最近中招<script src=http://s.see9.us/s.js></script>,比较郁闷,真是猖獗啊, 再回过头来看看代码中的拼接,发现几处 Request.QueryString并不是用参数传值,没有做限制,估计就是漏洞点,只有在补充过滤类,来限制了 1 /**/ /// <summary> 2 /// 过滤SQL注入关键字[post,get] 3 /// </summary> 4 /// <param name="pStr"></param> 5 /// <returns></returns> 6 public static string GetQueryStringSafe( string pStr) 7 { 8 bool IsValue = true ; 9 if (pStr != null && pStr.Length > 0 ) 10 { 11 pStr = pStr.ToLower(); 12 string strSQLin = " '|and|--|exec|insert|select|delete|update|count|*|%|chr|mid|master|truncate|char|declare |;|&|%20|==|>|< " ; 13 string [] strSQLinGroup = strSQLin.Split( new char

如何写出高性能的sql语句？ （1） 选择最有效率的表名顺序(只在基于规则的优化器中有效)： ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名，FROM子句中写在最后的表(基础表 driving table)将被最先处理，在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表。如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其他表所引用的表. （2） WHERE子句中的连接顺序．： ORACLE采用自下而上的顺序解析WHERE子句,根据这个原理,表之间的连接必须写在其他WHERE条件之前, 那些可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾. （3） SELECT子句中避免使用 ‘ * ‘： ORACLE 在解析的过程中, 会将'*' 依次转换成所有的列名, 这个工作是通过查询数据字典完成的, 这意味着将耗费更多的时间 （4） 减少访问数据库的次数： ORACLE在内部执行了许多工作: 解析SQL语句, 估算索引的利用率, 绑定变量 , 读数据块等； （5） 在SQL*Plus , SQL*Forms和Pro*C中重新设置ARRAYSIZE参数, 可以增加每次数据库访问的检索数据量 ,建议值为200 （6） 使用DECODE函数来减少处理时间：

-- SQL Server： Select TOP N * From TABLE Order By NewID () -- 开头到N条记录 Select Top N * From 表 -- N到M条记录(要有主索引ID) Select Top M - N * From 表Where ID in ( Select Top M ID From 表) Order by ID Desc -- 选择10从到15的记录 select top 5 * from ( select top 15 * from table order by id asc ) A order by id desc -- N到结尾记录 Select Top N * From 表Order by ID Desc 统计比例：0.11 select cast( (sum( case when id=2 then 1 else 0 end) +0.00)/Count(1) as decimal(18,2)) as 比例 from @rtb -- 显示最后5条记录,但是显示的顺序必须为5,6,7,8,9,10,而不是10,9,8,7,6,5 如下解决方法: select top 5 from test where id in ( select top 5 from test order by id desc ) order by