sql 优化3

InnoDB和MyISAM是在使用MySQL最常用的两个表类型，各有优缺点，视具体应用而定。基本的差别为：MyISAM类型不支持事务处理等高级处理，而InnoDB类型支持。MyISAM类型的表强调的是性能，其执行数度比InnoDB类型更快，但是不提供事务支持，而InnoDB提供事务支持已经外部键等高级数据库功能。

MyIASM是IASM表的新版本，有如下扩展： 
二进制层次的可移植性。 
NULL列索引。 
对变长行比ISAM表有更少的碎片。 
支持大文件。 
更好的索引压缩。 
更好的键吗统计分布。 
更好和更快的auto_increment处理。 

以下是一些细节和具体实现的差别：

1.InnoDB不支持FULLTEXT类型的索引。
2.InnoDB 中不保存表的具体行数，也就是说，执行select count(*) from table时，InnoDB要扫描一遍整个表来计算有多少行，但是MyISAM只要简单的读出保存好的行数即可。注意的是，当count(*)语句包含 where条件时，两种表的操作是一样的。
3.对于AUTO_INCREMENT类型的字段，InnoDB中必须包含只有该字段的索引，但是在MyISAM表中，可以和其他字段一起建立联合索引。
4.DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的删除。
5.LOAD TABLE FROM MASTER操作对InnoDB是不起作用的，解决方法是首先把InnoDB表改成MyISAM表，导入数据后再改成InnoDB表，但是对于使用的额外的InnoDB特性（例如外键）的表不适用。

另外，InnoDB表的行锁也不是绝对的，如果在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表，例如update table set num=1 where name like “%aaa%”

任何一种表都不是万能的，只用恰当的针对业务类型来选择合适的表类型，才能最大的发挥MySQL的性能优势。

Mysql的优化原则1：

1、使用索引来更快地遍历表。
缺省情况下建立的索引是非群集索引，但有时它并不是最佳的。在非群集索引下，数据在物理上随机存放在数据页上。合理的索引设计要建立在对各种查询的分析和预测上。一般来说：
a.有大量重复值、且经常有范围查询（ > ,< ，> =,< =）和order by、group by发生的列，可考虑建立群集索引；
b.经常同时存取多列，且每列都含有重复值可考虑建立组合索引；
c.组合索引要尽量使关键查询形成索引覆盖，其前导列一定是使用最频繁的列。索引虽有助于提高性能但不是索引越多越好，恰好相反过多的索引会导致系统低效。用户在表中每加进一个索引，维护索引集合就要做相应的更新工作。

MySQL能更高效地在声明具有相同类型和尺寸的列上使用索引。VARCHAR和CHAR是相同的，除非它们声明为不同的长度。
总的来说，要想使一个较慢速SELECT ... WHERE更快，应首先检查是否能增加一个索引。不同表之间的引用通常通过索引来完成。你可以使用EXPLAIN语句来确定SELECT语句使用哪些索引

2、在海量查询时尽量少用格式转换。

3、ORDER BY和GROPU BY使用ORDER BY和GROUP BY短语，任何一种索引都有助于SELECT的性能提高。
7、任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。
4、IN、OR子句常会使用工作表，使索引失效。如果不产生大量重复值，可以考虑把子句拆开。拆开的子句中应该包含索引。

 

Mysql的优化原则2：
1、只要能满足你的需求，应尽可能使用更小的数据类型：例如使用MEDIUMINT代替INT
2、尽量把所有的列设置为NOT NULL，如果你要保存NULL，手动去设置它，而不是把它设为默认值。
3、尽量少用VARCHAR、TEXT、BLOB类型
4、如果你的数据只有你所知的少量的几个。最好使用ENUM类型
5、正如graymice所讲的那样，建立索引。
以下是我做的一个实验，可以发现索引能极大地提高查询的效率：

我有一个会员信息表users，里边有37365条用户记录：

在不加索引的时候进行查询：
sql语句A:
select * from users where username like '%许%';
在Mysql-Front中的8次查询时长为：1.40,0.54,0.54,0.54,0.53,0.55,0.54 共找到960条记录

sql语句B:
select * from users where username like '许%';
在Mysql-Front中的8次查询时长为：0.53,0.53,0.53,0.54,0.53,0.53,0.54,0.54 共找到836条记录

sql语句C:
select * from users where username like '%许';
在Mysql-Front中的8次查询时长为：0.51,0.51,0.52,0.52,0.51,0.51,0.52,0.51 共找到7条记录

为username列添加索引:
create index usernameindex on users(username(6));

再次查询：
sql语句A:
select * from users where username like '%许%';
在Mysql-Front中的8次查询时长为：0.35,0.34,0.34,0.35,0.34,0.34,0.35,0.34 共找到960条记录

sql语句B:
select * from users where username like '许%';
在Mysql-Front中的8次查询时长为：0.06,0.07,0.07,0.07,0.07,0.07,0.06,0.06 共找到836条记录

sql语句C:
select * from users where username like '%许';
在Mysql-Front中的8次查询时长为：0.32,0.31,0.31,0.32,0.31,0.32,0.31,0.31 共找到7条记录


在实验过程中，我没有另开任何程序，以上的数据说明在单表查询中，建立索引的可以极大地提高查询速度。
另外要说的是如果建立了索引，对于like '许%'类型的查询，速度提升是最明显的。因此，我们在写sql语句的时候也尽量采用这种方式查询。

对于多表查询我们的优化原则是：

尽量将索引建立在：left join on/right join on ...　＋条件，的条件语句中所涉及的字段上。

多表查询比单表查询更能体现索引的优势。


6、索引的建立原则：
如果一列的中数据的前缀重复值很少，我们最好就只索引这个前缀。Mysql支持这种索引。我在上面用到的索引方法就是对username最左边的6个字符进行索引。索引越短，占用的磁盘空间越少，在检索过程中花的时间也越少。这方法可以对最多左255个字符进行索引。

在很多场合，我们可以给建立多列数据建立索引。

索引应该建立在查询条件中进行比较的字段上，而不是建立在我们要找出来并且显示的字段上

7、一往情深问到的问题:IN、OR子句常会使用工作表，使索引失效。如果不产生大量重复值，可以考虑把子句拆开。拆开的子句中应该包含索引。

这句话怎么理解决，请举个例子

例子如下:
如果在fields1和fields2上同时建立了索引，fields1为主索引
以下sql会用到索引
select * from tablename1 where fields1='value1' and fields2='value2'
以下sql不会用到索引
select * from tablename1 where fields1='value1' or fields2='value2'

死锁

死锁是一种条件，不仅仅是在关系数据库管理系统 (RDBMS) 中发生，在任何多用户系统中都可以发生的。当两个用户（或会话）具有不同对象的锁，并且每个用户需要另一个对象的锁时，就会出现死锁。每个用户都等待另一个用户释放他的锁。当两个连接陷入死锁时，Microsoft® SQL Server™ 会进行检测。其中一个连接被选作死锁牺牲品。该连接的事务回滚，同时应用程序收到错误。

如果死锁变成单个公用事件，而且它们的回滚造成过多的性能降级，那么就需要再次进行深入彻底的调查。使用跟踪标记 1204。例如，下面的命令从命令提示符启动 SQL Server，并启用跟踪标记 1204：

c:\mssql\binn\sqlservr -T1204

现在所有消息都会显示在启动 SQL Server 的控制台屏幕上和错误日志中。

使用分布式事务时，也可能发生死锁。

阻塞

任何基于锁的并发系统都不可避免地具有可能在某些情况下发生阻塞的特征。当一个连接控制了一个锁，而另一个连接需要冲突的锁类型时，将发生阻塞。其结果是强制第二个连接等待，或在第一个连接上阻塞。

在本主题中，术语"连接"是指数据库的单个登录会话。每个连接都作为系统进程 ID (SPID) 出现。尽管每一个 SPID 一般都不是单独的进程上下文，但这里常常用来指一个进程。更确切的说，每个 SPID 都是由服务器资源和数据结构（为给定客户单个连接的请求提供服务）组成。单个客户应用程序可能有一个或多个连接。就 SQL Server 而言，从单个客户机上的单个客户应用程序来的多个连接和从多个客户应用程序或多个客户机来的多个连接是没有区别的。不管是来自同一应用程序还是来自两台不同客户机上单独的应用程序，一个连接都可以阻塞另一个连接。 （责任编辑：卢兆林）

死锁

deadlocks（死锁）

  
所谓死锁<DeadLock>: 是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等待的进程称为死锁进程.
由于资源占用是互斥的，当某个进程提出申请资源后，使得有关进程在无外力协助下，永远分配不到必需的资源而无法继续运行，这就产生了一种特殊现象死锁。 一种情形，此时执行程序中两个或多个线程发生永久堵塞（等待），每个线程都在等待被其他线程占用并堵塞了的资源。例如，如果线程A锁住了记录1并等待记录2，而线程B锁住了记录2并等待记录1，这样两个线程就发生了死锁现象。 计算机系统中,如果系统的资源分配策略不当，更常见的可能是程序员写的程序有错误等，则会导致进程因竞争资源不当而产生死锁的现象。
产生死锁的原因主要是：

 

（1） 因为系统资源不足。

 

（2） 进程运行推进的顺序不合适。

（3） 资源分配不当等。

 

如果系统资源充足，进程的资源请求都能够得到满足，死锁出现的可能性就很低，否则 就会因争夺有限的资源而陷入死锁。其次，进程运行推进顺序与速度不同，也可能产生死锁。  
产生死锁的四个必要条件：

（1） 互斥条件：一个资源每次只能被一个进程使用。
（2） 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
（3） 不剥夺条件:进程已获得的资源，在末使用完之前，不能强行剥夺。
（4） 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。
这四个条件是死锁的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之一不满足，就不会发生死锁。
死锁的解除与预防：

理解了死锁的原因，尤其是产生死锁的四个必要条件，就可以最大可能地避免、预防和 解除死锁。所以，在系统设计、进程调度等方面注意如何不让这四个必要条件成立，如何确 定资源的合理分配算法，避免进程永久占据系统资源。此外，也要防止进程在处于等待状态的情况下占用资源,在系统运行过程中，对进程发出的每一个系统能够满足的资源申请进行动态检查，并根据检查结果决定是否分配资源，若分配后系统可能发生死锁，则不予分配，否则予以分配 。因此，对资源的分配要给予合理的规划。