sql查询优化策略

Posted 2020-10-12

Sql语句执行顺序：

查询的逻辑执行顺序

 　　(1) FROM left_table

　　(3) join_type JOIN right_table (2) ON join_condition

　　(4) WHERE where_condition

　　(5) GROUP BY group_by_list

　　(6) WITH {cube | rollup}

　　(7) HAVING having_condition

　　(8) SELECT (9) DISTINCT (11) top_specification select_list

　　(9) ORDER BY order_by_list

标准的 SQL 的解析顺序为:

　　(1) FROM 子句 组装来自不同数据源的数据

 　　(2) WHERE 子句 基于指定的条件对记录进行筛选

 　　(3) GROUP BY 子句 将数据划分为多个分组

 　　(4) 使用聚合函数进行计算

 　　(5) 使用HAVING子句筛选分组

 　　(6) 计算所有的表达式

 　　(7) 使用ORDER BY对结果集进行排序

执行顺序

 　　1. FROM：对FROM子句中前两个表执行笛卡尔积生成虚拟表vt1

　　2. ON: 对vt1表应用ON筛选器只有满足 join_condition 为真的行才被插入vt2

　　3. OUTER(join)：如果指定了 OUTER JOIN保留表(preserved table)中未找到的行将行作为外部行添加到vt2，生成t3，如果from包含两个以上表，则对上一个联结生成的

结果表和下一个表重复执行步骤和步骤直接结束。

 　　4. WHERE：对vt3应用 WHERE 筛选器只有使 where_condition 为true的行才被插入vt4

　　5. GROUP BY：按GROUP BY子句中的列列表对vt4中的行分组生成vt5

　　6. CUBE|ROLLUP：把超组(supergroups)插入vt6，生成vt6

　　7. HAVING：对vt6应用HAVING筛选器只有使 having_condition 为true的组才插入vt7

　　8. SELECT：处理select列表产生vt8

　　9. DISTINCT：将重复的行从vt8中去除产生vt9

　　10. ORDER BY：将vt9的行按order by子句中的列列表排序生成一个游标vc10

TOP：从vc10的开始处选择指定数量或比例的行生成vt11 并返回调用者

 

数据库的读写分离

实现原理：读写分离简单的说是把对数据库读和写的操作分开对应不同的数据库服务器，这样能有效地减轻数据库压力，也能减轻io压力。主数据库提供写操作，从数据库提供

读操作，其实在很多系统中，主要是读的操作。当主数据库进行写操作时，数据要同步到从的数据库，这样才能有效保证数据库完整性。

实现方法

SQL SERVER复制技术类型有三种，分别是：快照复制、事务复制、合并复制。

SQL SERVER 主要采用出版物、订阅的方式来处理复制。

2，优缺点

(1)数据的实时性差:数据不是实时同步到自读服务器上的，当数据写入主服务器后，要在下次同步后才能查询到。

　　(2)数据量大时同步效率差：单表数据量过大时插入和更新因索引,磁盘IO等问题，性能会变的很差。

　　(3)同时连接多个(至少两个)数据库：至少要连接到两个数据数据库，实际的读写操作是在程序代码中完成的，容易引起混乱

    (4)读具有高性能高可靠性和可伸缩:只读服务器，因为没有写操作，会大大减轻磁盘IO等性能问题，大大提高效率;只读服务器可以采用负载均衡，主数据库发布到多个只读

服务器上实现读操作的可伸缩性。

数据库/数据表 拆分(分布式)

通过某种特定的条件，将存放在同一个数据库中的数据分散存放到多个数据库上，实现分布存储，通过路由规则路由访问特定的数据库，这样一来每次访问面对的就不是单台

服务器了，而是N台服务器，这样就可以降低单台机器的负载压力。提示：sqlserver 2005版本之后，可以友好的支持“表分区”。

垂直(纵向)拆分：是指按功能模块拆分，比如分为订单库、商品库、用户库...这种方式多个数据库之间的表结构不同。水平(横向)拆分：将同一个表的数据进行分块保存到不同

的数据库中，这些数据库中的表结构完全相同。 ▲(纵向拆分)  水平(横向)拆分

临时表：

SqlServer中可以创建本地和全局临时表。本地临时表仅在当前会话中可见；全局临时表在所有会话中都可见。

本地临时表的名称前面有一个#，如(#table_name)，而全局临时表的名称前面有两个## ，如(##table_name)。

临时表与普通表的区别：

本地临时表,仅限于当前访问者访问,创建方法去如下:

create table #TableName(表结构)

储存于数据库tempdb内(硬盘),当前用户断开连接,自动删除

如果使用中不断开连接,且不需要该临时表请执行:drop table #TableName

全局临时表,所有访问用户访问,创建方法去如下:

create table ##TableName(表结构)

储存于数据库tempdb内,当所有访问用户断开连接,自动删除

删除语句:drop table ##TableName

--创建临时表

CREATE TABLE #MyTempTable (cola INT PRIMARY KEY)

--向临时表，插入数据

INSERT INTO #MyTempTable VALUES (1)

--向临时表中批量复制数据

insert into #tablename(a,b,c,d) select a,b,c,d from T

 

sqlserver 多库查询sp_addlinkedserver

mssql在使用多库查询的时候会用到链接服务器，以下为链接服务器的添加方法，添加完了即可实现任意改服务器的多库查询了

Exec sp_droplinkedsrvlogin ZYB,Null --删除映射（录与链接服务器上远程登录之间的映射）

Exec sp_dropserver ZYB --删除远程服务器链接

EXEC sp_addlinkedserver

@server=‘ZYB‘,--被访问的服务器别名

@srvproduct=‘‘,

@provider=‘SQLOLEDB‘,

@datasrc="/Server2" --要访问的服务器

EXEC sp_addlinkedsrvlogin

‘ZYB‘, --被访问的服务器别名

‘false‘,

NULL,

‘sa‘, --帐号

‘sa‘ --密码

使用实例：

Select * from ZYB.CDCenter20110822.dbo.cardbase

 

数据库弱一致性四个隔离级别

SQL-92标准中定义了四个隔离级别，这四个隔离级别在以前版本的SQL Server中即受到支持：

READ UNCOMMITTED

READ UNCOMMITTED是限制性最弱的隔离级别，因为该级别忽略其他事务放置的锁。使用READ UNCOMMITTED级别执行的事务，可以读取尚未由其他事务提交的修改后

的数据值，这些行为称为“脏”读。这是因为在Read Uncommitted级别下，读取数据不需要加S锁，这样就不会跟被修改的数据上的X锁冲突。比如，事务1修改一行，事务2在

事务1提交之前读取了这一行。如果事务1回滚，事务2就读取了一行没有提交的数据，这样的数据我们认为是不存在的。

READ COMMITTED

READ COMMITTED(Nonrepeatable reads)是SQL Server默认的隔离级别。该级别通过指定语句不能读取其他事务已修改但是尚未提交的数据值，禁止执行脏读。在当前事务

中的各个语句执行之间，其他事务仍可以修改、插入或删除数据，从而产生无法重复的读操作，或“影子”数据。比如，事务1读取了一行，事务2修改或者删除这一行并且提交。

如果事务1想再一次读取这一行，它将获得修改后的数据或者发现这一样已经被删除，因此事务的第二次读取结果与第一次读取结果不同，因此也叫不可重复读。

实验1

query1：事务1

--step1:创建实验数据select * into Employee from AdventureWorks.HumanResources.Employe

alter table Employee add constraint pk_Employee_EmployeeID primary key(EmployeeID)

--step2:设置隔离级别,这是数据库的默认隔离界别SET TRANSACTION ISOLATION LEVEL READ COMMITTED

--step3:开启第一个事务BEGIN TRAN tran1

    --step4:执行select操作,查看VacationHours,对查找的记录加S锁，在语句执行完以后自动释放S锁

    SELECT EmployeeID, VacationHours

        FROM Employee 

        WHERE EmployeeID = 4;

    --step5:查看当前加锁情况,没有发现在Employee表上面有锁,这是因为当前的隔离界别是READ COMMITTED

    --在执行完step2以后马上释放了S锁.

    SELECT request_session_id, resource_type, resource_associated_entity_id,

        request_status, request_mode, resource_description

        FROM sys.dm_tran_locks

查看锁的情况如下图所示，我们发现在只有在数据库级别的S锁，而没有在表级别或者更低级别的锁，这是因为在Read Committed级别下，S锁在语句执行完以后就被释放。

 

query2：事务2

--step6:开启第二个事务BEGIN TRAN tran2;

    --step7:修改VacationHours,需要获得排它锁X,在VacationHours上没有有S锁

    UPDATE Employee 

        SET VacationHours = VacationHours - 8  

        WHERE EmployeeID = 4;

    --step8:查看当前加锁情况

    SELECT request_session_id, resource_type, resource_associated_entity_id,

        request_status, request_mode, resource_description

        FROM sys.dm_tran_locks

在开启另外一个update事务以后，我们再去查看当前的锁状况，如下图所示，我们发现在表(Object)级别上加了IX锁，在这张表所在的Page上也加了IX锁，因为表加了聚集索引，

所以在叶子结点上加了X锁，这个锁的类型是KEY。

 

然后我们回到事务1当中再次执行查询语句，我们会发现查询被阻塞，我们新建一个查询query3来查看这个时候的锁状况，其查询结果如下，我们可以 发现查询操作需要在KEY

级别上申请S锁，在Page和表(Object)上面申请IS锁，但是因为Key上面原先有了X锁，与当前读操作申请的S锁冲 突，所以这一步处于WAIT状态。

 

如果此时提交事务2的update操作，那么事务1的select操作不再被阻塞，得到查询结果，但是我们发现此时得到的查询结果与第一次得到的查询结果不同，这也是为什么将

read committed称为不可重复读，因为同一个事物内的两次相同的查询操作的结果可能不同。

REPEATABLE READ

REPEATABLE READ是比READ COMMITTED限制性更强的隔离级别。该级别包括READ COMMITTED，并且另外指定了在当前事务提交之前，其他任何事务均不可以修改或

删除当前事务已读取的数据。并发性低于 READ COMMITTED，因为已读数据的共享锁在整个事务期间持有，而不是在每个语句结束时释放。比如，事务1读取了一行，事务2

想修改或者删除这一行并且提交，但是因为事务1尚未提交，数据行中有事务1的锁，事务2无法进行更新操作，因此事务2阻塞。如果这时候事务1想再一次读取这一行，它读取

结果与第一次读取结果相同，因此叫可重复读。

实验2

query1：事务1

--step1:创建实验数据select * into Employee from AdventureWorks.HumanResources.Employeealter table Employee add constraint pk_Employee_EmployeeID primary key(EmployeeID)

--step2:设置隔离级别SET TRANSACTION ISOLATION LEVEL REPEATABLE READ

--step3:开启第一个事务BEGIN TRAN tran1

    --step4:执行select操作,查看VacationHours

    SELECT EmployeeID, VacationHours

        FROM Employee 

        WHERE EmployeeID = 4;

    --step5:查看当前加锁情况,发现在Employee表上面有S锁,这是因为当前的隔离界别是REPEATABLE READ

    --S锁只有在事务执行完以后才会被释放.

    SELECT request_session_id, resource_type, resource_associated_entity_id,

        request_status, request_mode, resource_description

        FROM sys.dm_tran_locks

查询锁状态的结果如下图所示，我们发现在KEY上面加了S锁，在Page和Object上面加了IS锁，这是因为在Repeatable Read级别下S锁要在事务执行完以后才会被释放。

 

 query2：事务2

--step6:开启第二个事务BEGIN TRAN tran2;

    --step7:修改VacationHours,需要获得排他锁X,在VacationHours上有S锁，出现冲突，所以update操作被阻塞

    UPDATE Employee 

        SET VacationHours = VacationHours - 8  

        WHERE EmployeeID = 4;

执行上述update操作的时候发现该操作被阻塞，这是因为update操作要加排它锁X，而因为原先的查询操作的S锁没有释放，所以两者冲突。我们新建一个查询3执行查询

锁状态操作，发现结果如下图所示，我们可以发现是WAIT发生在对KEY加X锁的操作上面。

 

此时再次执行查询1中的select操作，我们发现查询结果跟第一次相同，所以这个叫做可重复读操作。但是可重复读操作并不是特定指两次读取的数据 一模一样，

Repeatable Read存在的一个问题是幻读，就是第二次读取的数据返回的条目数比第一次返回的条目数更多。

比如在Repeatable Read隔离级别下，事务1第一次执行查询select id from users where id>1 and id <10，返回的结果是2，4，6，8。这个时候事务1没有提交，那么对

2，4，6，8上面依然保持有S锁。此时事务2执行一次插入操作insert into user(id) valuse(3)，插入成功。此时再次执行事务1中的查询，那么返回结果就是2，3，4，6，8。

这里的3就是因为幻读而出现的。因此可以得出结论：REPEATABLE READ隔离级别保证了在相同的查询条件下，同一个事务中的两个查询，第二次读取的内容肯定包换第

一次读到的内容。

SERIALIZABLE 

SERIALIZABLE 是限制性最强的隔离级别，因为该级别锁定整个范围的键，并一直持有锁，直到事务完成。该级别包括REPEATABLE READ，并增加了在事务完成之前，

其他事务不能向事务已读取的范围插入新行的限制。比如，事务1读取了一系列满足搜索条件的行。事务2在执行SQL statement产生一行或者多行满足事务1搜索条件的行

时会冲突，则事务2回滚。这时事务1再次读取了一系列满足相同搜索条件的行，第二次读取的结果和第一次读取的结果相同。

重复读与幻读

重复读是为了保证在一个事务中，相同查询条件下读取的数据值不发生改变，但是不能保证下次同样条件查询，结果记录数不会增加。

幻读就是为了解决这个问题而存在的，他将这个查询范围都加锁了，所以就不能再往这个范围内插入数据，这就是SERIALIZABLE 隔离级别做的事情。

隔离级别与锁的关系

1.      在Read Uncommitted级别下，读操作不加S锁；

2.      在Read Committed级别下，读操作需要加S锁，但是在语句执行完以后释放S锁；

3.      在Repeatable Read级别下，读操作需要加S锁，但是在事务提交之前并不释放S锁，也就是必须等待事务执行完毕以后才释放S锁。

4.      在Serialize级别下，会在Repeatable Read级别的基础上，添加一个范围锁。保证一个事务内的两次查询结果完全一样，而不会出现第一次查询结果是第二次查询结

         果的子集。

什么是View视图，何时应用？

视图是一个虚拟表，其是存储在数据库中的查询的SQL语句。视图中的数据是在被引用时动态生成的。

使用时可以基于以下情况：

１　需要隐藏一些数据时

２　需要从一个或多个表导出数据

３　安全性

存储过程的优点

1.创建一次，多次调用。

2.更快执行，如果某操作需要执行大量SQL语句或重复执行，存储过程比SQL语句执行要快。

3.减少网络流量，例如一个需要数百行的SQL代码的操作有一条执行语句完成，不需要在网络中发送数百行代码。

4.更好的安全机制，对于没有权限执行存储过程的用户，也可授权他们执行存储过程。

 

左链接   右连接

Left  join左连接是查询JOIN左边的表中的所有记录（包括右边表中与其没有相匹配的记录）

Right join右连接是查询JOIN左边的表中的所有记录（包括左边表中与其没有相匹配的记录）

Inner join内连接是查询JOIN左边的表中的所有记录（左、右表中必须匹配的记录）

全连接是查询JOIN左边的表中的所有记录（包括右边表中与其没有相匹配的记录，以及左边表中与其没有相匹配的记录）

例

select * from A left join B on A.id=B.id             左链接

select * from A right join B on A.id=B.id           右连接

--两表连接

SELECT  S.NAME,T.NAME FROM STUDENT AS S INNER JOIN TEACHER AS T ON S. CNO = T. CNO ORDER BY  SNAME

--三表连接

select a.*,c.f from (select * from a inner join b on a.a = b.a) as a inner join c on a.d = c.d

SQL truncate 、delete与drop区别

    truncate 和 delete 只删除数据不删除表的结构(定义)

    drop 语句将删除表的结构被依赖的约束(constrain)、触发器(trigger)、索引(index)；依赖于该表的存储过程/函数将保留,但是变为 invalid 状态。

    delete 语句是数据库操作语言(dml)，这个操作会放到 rollback segement 中，事务提交之后才生效；

    truncate、drop 是数据库定义语言(ddl)，操作立即生效，原数据不放到 rollback segment 中，不能回滚，操作不触发 trigger。

    delete 语句不释放所占用的存储空间

    drop 语句将表所占用的空间全部释放。

速度，一般来说: drop > truncate > delete

DDL和DML分别代表什么？

DDL表示数据定义语言，主要包括CREATE，ALTER，DROP，...等;

DML表示数据操作语言，主要有SELECT，INSERT，UPDATE，DELETE等.

维护数据库的完整性、一致性、你喜欢用触发器还是自写业务逻辑？为什么?

答：尽可能用约束（包括CHECK、主键、唯一键、外键、非空字段）实现，这种方式的效率最好；其次用触发器，这种方式可以保证无论何种业务系统访问数据库都能

维持数据库的完整性、一致性；最后再考虑用自写业务逻辑实现，但这种方式效率最低、编程最复杂，当为下下之策。

游标是什么

    游标对查询出来的结果集作为一个单元来有效的处理，游标可以定位在结果集的特定行、从结果集的当前位置检索一行或多行、可以对结果集中当前位置的数据进行修改。

    游标是系统为用户开设的一个数据缓冲区，存放SQL语句的执行结果，每个游标区都有一个名字，可以用fetch 语句逐一从游标中获取记录，并赋给变量，对游标中的

数据进行依次读取处理。

    显然，使用游标可以对数据集进行循环处理，在一些特定的情况下，是非常有作用的，但是游标存在效率问题，特别是存储数据量比较大时；

在具体应用中，如果数据表中有几十万或者更大量的数据时，游标的效率是要考虑的。

因为游标相当于在这么大的表中不停地查找，直到你想要的结果，实际上与你一个特征一个特征地取数据是一样的，只是那样子你也穷举无数种可能，而游标在这种情况

下会按一种你定义的规则自动进行。

例：

declare @id nvarchar(20)  --定义变量来保存ID号

declare @A float                  --定义变量来保存值

declare mycursor cursor for select * from tb_c   --为所获得的数据集指定游标

open mycursor                   --打开游标

fetch next from mycursor  into @id,@A   --开始抓第一条数据

while(@@fetch_status=0)     --如果数据集里一直有数据

begin

 select tb_b.name,(tb_b.gz + @A) from tb_b where tb_b.id = @id   --开始做想做的事（什么更新呀，删除呀）

        fetch next from mycursor into @id,@A     --跳到下一条数据

end

close mycursor        --关闭游标

deallocate mycursor  --删除游标

Sql查询题

Sql查询时的case关键词使用

在成绩表中，效率60分为不及格，大于60分为及格，大于80分为优秀，请用一条SQL语句查询。

答：设有成绩表Scores  包含字段ScoreId  Score

查询语句如下：

Select 成绩=case

    When  score  between(0 and 59) then ‘不及格’

    When  score  between(60 and 79)  then ‘及格’

    When   score between(80 and 100) then ‘优秀’

    Else ‘无效成绩’

    End

From Score

请用SQL语句查处当天所有记录.

答： select * from tb_send where datediff(day,sendTime, getdate())=0

sql查询，表table(id,lastUpdateDate);使用一条sql语句查出最近一次的修改时间

答：select top 1 lastUpdateDate from [table] order by lastUpdateDate desc

游标的声明与使用，如何判断记录已到达最末尾

declare @myCur Cursor

declare mySet Cursor for

select * from 表名

set @muCur=mySet

open mySet

fetch next from mySet

while @@FETCH_STATUS=0

begin

fetch next from mySet

end

close mySet

deallocate mySet

性能优化

程序访问数据库记录速度很慢，分析什么原因造成以及解决办法。

答案：

原因很多种，其可能的典型如下：

查询语句本身造成的。优化语句

表结构问题。增加索引

网络环境造成。优化网络

系统瓶颈。优化系统

硬件造成的。升级硬件

索引的概念

索引就是加快查询表中数据的方法。

数据库的索引类似于书籍的索引。

在书籍中，索引允许用户不必翻阅完整个书就能迅速地找到所需要的信息。

在数据库中，索引也允许数据库程序迅速地找到表中的数据，而不必扫描整个数据库.

索引的特点

1.索引可以加快数据库的检索速度

2.索引降低了数据库插入、修改、删除等维护任务的速度，因为数据变化后，需要同步维护索引。

3.索引只能创建在表上，不能创建在视图上

索引的优点

1.创建唯一性索引，保证数据库表中每一行数据的唯一性

2.大大加快数据的检索速度，这也是创建索引的最主要的原因

3.减少磁盘IO

索引的缺点

  1.创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加

  2.索引需要占物理空间，除了数据表占数据空间之外，索引还要占一定的物理空间

  3.当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，降低了数据的维护速度

微软的SQL SERVER提供了两种索引：

聚集索引(clustered index)

非聚集索引(nonclustered index)

聚集索引中键值的逻辑顺序决定了表中相应行的物理存储顺序。

适用场合：

  含有大量非重复值的列

  会使用BETWEEN,>,>=,<或<=返回一个范围值的列

  会被连续访问的列

  返回大型结果集的查询

  经常被使用连接或GROUP BY子句的查询访问的列

如果用 新华字典 作例子来一个例子的话。

  [拼音]就可以看作是聚集索引

    例如 吖、阿、啊 在字典的最前面。

    左、作、坐 在字典的最后面。

    拼音[逻辑顺序]很接近，在字典中页数的位置[物理顺序]也很接近。

而非聚集索引是不将表和视图中的数据进行物理排序。

  非聚集索引与聚集索引一样有 B 树结构，但是有两个重大差别：

  数据行不按非聚集索引键的顺序排序和存储。

  非聚集索引的叶层不包含数据页。

  相反，叶节点包含索引行。每个索引行包含非聚集键值以及一个或多个行定位器，

  这些行定位器指向有该键值的数据行（如果索引不唯一，则可能是多行）。

适用场合：

  含有大量非重复值的列

  非连续访问的列

  返回小型结果集的查询

如果用 新华字典 作例子来一个例子的话。

  [笔画]就可以看作是非聚集索引

    例如 化 仇 仃 仅 仂 这几个字，都是 单人旁，笔画数相同的。

    笔画[逻辑顺序]很接近，在字典中页数的位置[物理顺序]则在不同的位置上。

SqlServer中支持在表和视图上，添加索引。

一个表或视图中最多可以有250个非聚集索引 或 有249个非聚集索引 + 一个聚集索引。

如何处理几百万条并发数据？

答：具体处理可以有很多方案，

比如使用存储过程+事务，保证数据植入的速度，及原子性问题。在植入标识时，注意主键是不是自增量方式这种方法，并发的时候是不会有重复主键的问题，如果没有

使用自增量方式，生成标识的工作最好使用存储过程来完成.

还可以使用以下技术来优化，那块好，可以扩展谈一下，不好算了

使用队列机

使用事务，保持原子性。

引入锁机制。

可以控制连接池的连接数量,

负载均衡

如果有100万条记录，请问你如何优化表结构查询提高速度？

一．水平分割

根据一列或多列数据的值把数据行放到两个独立的表中。即按记录进分分割，不同的记录可以分开保存，每个子表的列数相同。

水平分区将表分为多个表。每个表包含的列数相同，但是行更少。例如，可以将一个包含十亿行的表水平分区成 12 个表，每个小表表示特定年份内一个月的数据。任何

需要特定月份数据的查询只需引用相应月份的表。

水平分割通常在下面的情况下使用：

（1）    表很大，分割后可以降低在查询时需要读的数据和索引的页数，同时也降低了索引的层数，提高查询速度。

（2）    表中的数据本来就有独立性，例如表中分别记录各个地区的数据或不同时期的数据，特别是有些数据常用，而另外一些数据不常用。

（3）    需要把数据存放到多个介质上。

水平分割会给应用增加复杂度，它通常在查询时需要多个表名，查询所有数据需要union操作。在许多数据库应用中，这种复杂性会超过它带来的优点，因为只要索引关

键字不大，则在索引用于查询时，表中增加两到三倍数据量，查询时也就增加读一个索引层的磁盘次数。

二．垂直分割

垂直分割表（不破坏第三范式），把主码和一些列放到一个表，然后把主码和另外的列放到另一个表中。将原始表分成多个只包含较少列的表。如果一个表中某些列常用，

而另外一些列不常用，则可以采用垂直分割，另外垂直分割可以使得数据行变小，一个数据页就能存放更多的数据，在查询时就会减少I/O次数(每次查询时读取的block 就

少)。其缺点是需要管理冗余列，查询所有数据需要join操作。

垂直分割表可以达到最大化利用Cache的目的。

其它优化手段：

1.合理的使用索引（例如在频繁作为条件的列，经常作为排序或分组的列）

2.只查询必要的列，避免 *

3.按已建立索引的列进行数据查询

4.避免或简化排序，并避免按非索引列排序输出

5.使用存储过程，减少服务器通讯次数，尽量多个处理一次提交。

存储过程：

存储过程（Stored Procedure）是一组为了完成特定功能的SQL语句集，经编译后存储在数据库中。用户通过指定存储过程的名字并给出参数（如果该存储过程带有参

数）来执行它。存储过程是数据库中的一个重要对象。

存储过程和sql语句的优缺点

优点：

1.提高性能，减少网络传输，节约时间 。

2.减少网络流量    存储过程位于服务器上，调用的时候只须传递存储过程的名称以及参数，不用每次访问都传递很长的sql 语句。

4.安全性 减少sql 注入式攻击。

5.可维护性高 更新存储过程通常比更改、测试以及重新部署程序集需要较少的时间和精力。

缺点：

1.交互性差 。

2.可移植性差

什么是存储过程？有什么优点？

答：存储过程是一组予编译的SQL语句

    它的优点：

    1.允许模块化程序设计，就是说只需要创建一次过程，以后在程序中就可以调用该过程任意次。

    2.允许更快执行，如果某操作需要执行大量SQL语句或重复执行，存储过程比SQL语句执行的要快。

    3.减少网络流量，例如一个需要数百行的SQL代码的操作有一条执行语句完成，不需要在网络中发送数百行代码。

　　4.更好的安全机制，对于没有权限执行存储过程的用户，也可授权他们执行存储过程。

事务：

事务(Transaction)是访问并可能更新数据库中各种数据项的一个程序执行单元(unit)。事务是恢复和并发控制的基本单位。

事务应满足：原子性、一致性、隔离性、持续性等要求。这四个要求通常称为ACID特性。

原子性（atomicity）。一个事务是一个不可分割的工作单位，事务中包括的诸操作要么都做，要么都不做。

一致性（consistency）。事务必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。

隔离性（isolation）。一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。

持久性（durability）。持续性也称永久性（permanence），指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其

有任何影响。

事务是指一个工作单元，它包含了一组数据操作命令，并且所有的命令作为一个整体一起向系统提交或撤消请求操作，即这组命令要么都执行，要么都不执行。

在应用中，使用事务的手段：

1.      在数据库t-sql编程中，如存储过程：

begin transaction

commit transaction

rollback transaction

begin transaction

--修改数据

--判断修改数据是否出现异常

      if @@ERROR<>0

        begin

          rollback transaction

        end

      else

        begin

          commit transaction

2.            End

3.      在ado.net中

SqlTransaction trans = conn.BeginTransaction();//开启conn连接的事务处理

trans.Commit();  事务提交

trans.Rollback();//对于conn连接的数据库操作都会被回滚

         SqlConnection conn = Database.GetConn();

         SqlTransaction st = conn.BeginTransaction();

         try

         {

           

             string sql = "Insert Into T_Test(F_Name) values(‘A‘)";           

             Database.ExecuteNonQuery(st, CommandType.Text, sql);

 

            //这里会报错，在挂起的事务中，该事务分配的连接，不能再独占使用

             //string A = Database.ExecuteScalarToStr(conn,CommandType.Text,"Select F_ID From T_Test where F_Name=‘A‘");

            

             sql = "Insert Into T_Test2(F_ID,F_Age) values(1,2)";

             Database.ExecuteNonQuery(st, CommandType.Text, sql);

             st.Commit();          

          

         }

         catch (Exception Ex)

         {

             st.Rollback();

             Website.WriteError(Ex);

         }

         finally

         {

             Database.Dispose(conn);

4.               }

5.      在EF中

使用db.BeginTransaction（）开始一个事务

使用db.Commit（）提交一个事务

使用db.Rollback()回滚一个事务。

如何优化数据库?

       *（1、表优化（数据类型，定长，尽量不用Identity、定长的字段尽量放在前面）

        （2、查询优化（{不能用select*、having、去掉重复项、IS NULL"、 ""、"!="、"!", "!", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE", and "LIKE ‘%500‘}）

       *（3、用存储过程

       *（4、索引（更新速度慢，查询速度快）

        （5、视图、临时表（少用）

       *（6、不用游标

       *（7、横向、纵向分割表

       *（8、数据库读写分离（数据同步，sql中有订阅与发布功能）

       * (9、分布式

        （10、分页

        （11、锁

数据库查询优化，请给出以下问题的解决方案

1、多态性，多种数据库兼容；

2、支持翻页，支持查询总数，页码显示；

3、能处理100万以上数据量；

什么是锁

锁是实现数据库并 发控制的一个非常重要的技术。在并发执行时，会出现资源的竞争问题。所以可以使用锁，锁定相关资源。锁一般可分为排它锁、共享锁。

什么是死锁，如何避免死锁？

死锁的四个必要条件

在计算机专业的本科教材中，通常都会介绍死锁的四个必要条件。这四个条件缺一不可，或者说只要破坏了其中任何一个条件，死锁就不可能发生。我们来复习一下，

这四个条件是：

互斥（Mutual exclusion）：存在这样一种资源，它在某个时刻只能被分配给一个执行绪（也称为线程）使用；

持有（Hold and wait）：当请求的资源已被占用从而导致执行绪阻塞时，资源占用者不但无需释放该资源，而且还可以继续请求更多资源；

不可剥夺（No preemption）：执行绪获得到的互斥资源不可被强行剥夺，换句话说，只有资源占用者自己才能释放资源；

环形等待（Circular wait）：若干执行绪以不同的次序获取互斥资源，从而形成环形等待的局面，想象在由多个执行绪组成的环形链中，每个执行绪都在等待下一个

执行绪释放它持有的资源。

解决方法：

1 使用事务时，尽量缩短事务的逻辑处理过程，及早提交或回滚事务； (细化处理逻辑，执行一段逻辑后便回滚或者提交，然后再执行其它逻辑，直到事物执行完毕提交)

2 设置死锁超时参数为合理范围，如：3分钟-10分种；超过时间，自动放弃本次操作，避免进程悬挂；

3 优化程序，检查并避免死锁现象出现；

4 .对所有的脚本和SP都要仔细测试，在正是版本之前。

5 所有的SP都要有错误处理（通过@error）

6 一般不要修改SQL SERVER事务的默认级别。不推荐强行加锁另外参考的解决方法：

按同一顺序访问对象

    如果所有并发事务按同一顺序访问对象，则发生死锁的可能性会降低。例如，如果两个并发事务获得 Supplier 表上的锁，然后获得 Part 表上的锁，则在其中一个

事务完成之前，另一个事务被阻塞在 Supplier 表上。第一个事务提交或回滚后，第二个事务继续进行。不发生死锁。将存储过程用于所有的数据修改可以标准化访问对象的顺序。

   

    避免事务中的用户交互

    避免编写包含用户交互的事务，因为运行没有用户交互的批处理的速度要远远快于用户手动响应查询的速度，例如答复应用程序请求参数的提示。例如，如果事务正

在等待用户输入，而用户去吃午餐了或者甚至回家过周末了，则用户将此事务挂起使之不能完成。这样将降低系统的吞吐量，因为事务持有的任何锁只有在事务提交或

回滚时才会释放。即使不出现死锁的情况，访问同一资源的其它事务也会被阻塞，等待该事务完成。

   

    保持事务简短并在一个批处理中

    在同一数据库中并发执行多个需要长时间运行的事务时通常发生死锁。事务运行时间越长，其持有排它锁或更新锁的时间也就越长，从而堵塞了其它活动并可能导致

死锁。保持事务在一个批处理中，可以最小化事务的网络通信往返量，减少完成事务可能的延迟并释放锁。

   

    使用低隔离级别

    确定事务是否能在更低的隔离级别上运行。执行提交读允许事务读取另一个事务已读取（未修改）的数据，而不必等待第一个事务完成。使用较低的隔离级别（例如

提交读）而不使用较高的隔离级别（例如可串行读）可以缩短持有共享锁的时间，从而降低了锁定争夺。

   

    使用绑定连接

    使用绑定连接使同一应用程序所打开的两个或多个连接可以相互合作。次级连接所获得的任何锁可以象由主连接获得的锁那样持有，反之亦然，因此不会相互阻塞。

死锁的必要条件?怎么克服?

答：系统的资源不足，进程的推进的顺序不合适，资源分配不当，一个资源每次只能被一个进程使用，一个

资源请求资源时，而此时这个资源已阻塞，对已获得资源不放，进程获得资源时，未使用完前，不能强行剥夺。

在查询和更新数据时，会涉及到那几种类型的锁。

答：

1.共享锁  用于只读操作(select)，锁定共享的资源。共享锁不会阻止其他用户读，但是阻止其他的用户写和修改。

2.更新锁   更新锁是一种意图锁，当一个事务已经请求共享琐后并试图请求一个独占锁的时候发生更新琐。例如当两个事务在几行数据行上都使用了共享锁，并同时

试图获取独占锁以执行更新操作时，就发生了死锁：都在等待对方释放共享锁而实现独占锁。更新锁的目的是只让一个事务获得更新锁，防止这种情况的发生。

3.独占锁  一次只能有一个独占锁用在一个资源上，并且阻止其他所有的锁包括共享缩。写是独占锁，可以有效的防止’脏读’。

4.意图缩  在使用共享锁和独占锁之前，使用意图锁。从表的层次上查看意图锁，以判断事务能否获得共享锁和独占锁，提高了系统的性能，不需从页或者行上检查。

计划锁   sch-m,sch-s。对数据库结构改变时用sch-m，对查询进行编译时用sch-s。这两种锁不会阻塞任何事务锁，包括独占锁。

什么是锁

锁是在多用户环境中对数据的访问的限制。SqlServer自动锁定特定记录、字段或文件，防止用户访问，以维护数据安全或防止并发数据操作问题，锁可以保证事务的

完整性和并发性。

什么叫SQL注入？如何防止？请举例说明

答：SQL注入是常见的利用程序漏洞进行攻击的方法。导致sql注入攻击并非系统造成的，主要是程序中忽略了安全因素，利用sql语言漏洞获得合法身份登陆系统

例如：

"Select * from users where name=‘"+uName+"‘ and pwd=‘"+uPwd+"‘ "

如用户在t_name中输入tom’ or 1=‘1 就可以进入系统了。

生成语句：

Select * from users where name = ‘tom’ or 1=‘1’ and pwd=‘123’

怎样防止SQL注入？

 所谓SQL注入，就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令，比如先前的很多影视网站

泄露VIP会员密码大多就是通过WEB表单递交查询字符暴出的，这类表单特别容易受到SQL注入式攻击．

防范方法：

1、使用Parameter提交数据

2、使用存储过程开发数据库应用

3、使用关键词过滤技术

4、检查用户输入的合法性

 

 

1.对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。

2.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：   select id from t where num is null   可以在num上设置默认值0，

   确保表中num列没有null值，然后这样查询：  select id from t where num=0  

3.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。  

4.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：   select id from t where num=10 or num=20  可以这样查询：  

   select id from t where num=10  union all   select id from t where num=20  

5.in 和 not in 也要慎用，否则会导致全表扫描，如：  select id from t where num in(1,2,3)   对于连续的数值，能用 between 就不要用 in 了： 

   select id from t where num between 1 and 3 

6.下面的查询也将导致全表扫描：   select id from t where name like ‘%abc%‘  若要提高效率，可以考虑全文检索。  

7.如果在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。

   然 而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：  select id from t where [email protected]  可以改为强制

   查询使用索引：   select id from t with(index(索引名)) where [email protected]  

8.应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：   select id from t where num/2=100  应改为:   select id from t where

   num=100*2

 9.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：  

     select id from t where substring(name,1,3)=‘abc‘--name以abc开头的id   select id from t where datediff(day,createdate,‘2005-11-30‘)=0--‘2005-11-30’生成的id  应改为:  

     select id from t where name like ‘abc%‘   select id from t where createdate>=‘2005-11-30‘ and createdate<‘2005-12-1‘  

10.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。  

11.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能

     的让字段顺序与索引顺序相一致。 

12.不要写一些没有意义的查询，如需要生成一个空表结构：  select col1,col2 into #t from t where 1=0   这类代码不会返回任何结果集，但是会消耗系统资源的，应改成这样：

    create table #t(...)  

13.很多时候用 exists 代替 in 是一个好的选择：   select num from a where num in(select num from b)  用下面的语句替换：  

     select num from a where exists(select 1 from b where num=a.num) 

14.并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引，如一表中有字段sex，male、female几乎

     各一半，那么即使在sex上建了索引也对查询效率起不了作用。  

15.索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要

     慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有 必要。  

16.应尽可能的避免更新 clustered 索引数据列，因为 clustered 索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将导致整个表记录的顺序的调整，会耗费相当大的

     资源。若应用系统需要频繁更新 clustered 索引数据列，那么需要考虑是否应将该索引建为 clustered 索引。  

17.尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串

中每一个字符，而对于数字型而言只需要比较一次就够了。  

18.尽可能的使用 varchar/nvarchar 代替 char/nchar ，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。  

19.任何地方都不要使用 select * from t ，用具体的字段列表代替“*”，不要返回用不到的任何字段。  

20.尽量使用表变量来代替临时表。如果表变量包含大量数据，请注意索引非常有限（只有主键索引）。  

21.避免频繁创建和删除临时表，以减少系统表资源的消耗。  

22.临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件，最好使用导出表。  

23.在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果数据量不大，为了缓和系统表的资源，

    应先create table，然后insert。  

24.如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先 truncate table ，然后 drop table ，这样可以避免系统表的较长时间锁定。  

25.尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该考虑改写。  

26.使用基于游标的方法或临时表方法之前，应先寻找基于集的解决方案来解决问题，基于集的方法通常更有效。  

27.与临时表一样，游标并不是不可使用。对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法，尤其是在必须引用几个表才能获得所需的数据时。在结果

    集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时 间允许，基于游标的方法和基于集的方法都可以尝试一下，看哪一种方法的效果更好。  

28.在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ，在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 

    DONE_IN_PROC 消息。

29.尽量避免大事务操作，提高系统并发能力。

30.尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。