标签：time sql语句 三范式 比较 取数据 存储引擎 不可 har 区分
内容大多来自《高性能MySQL》，坦白说，这种英译的书看得特别蛋疼。内容大多是直译的，理解起来很费劲，似懂非懂的。
mysql 介绍：
mysql 是一种关系型数据库，它的架构可以在多种不同场景中应用，它很灵活，能够适应高要求的环境。它既可以嵌入到应用程序中，也可以支持数据仓库、内容索引和部署软件、高可用的冗余系统、在线事务处理系统等各种类型。
mysql 逻辑架构（四层）：
连接与线程处理 / 查询缓存 与 解析器 / 优化器 / 存储引擎
数据的锁主要用来保证数据的一致性的，数据库的锁从锁定的粒度上可以分为表级锁、行级锁和页级锁。
mysql 锁粒度：在给定的资源上，锁定的数据量越少，则系统并发程度越高，只要相互之间不发生冲突即可。所谓销策略，就是在销的开销和数据安全性之间寻求平衡。
表锁：会锁定整张表，开销最小。用户对表进行写操作，需要先获得表写锁。
事务的特点（ACID）：一组原子性的SQL操作。
原子性：最小工作单元，要么全部成功提交，要么失败全部回滚。
一致性：事务未提交时，任何修改都不会保存。
隔离性：一个事务所做的修改在提交之前，对其他事务是不可见的。
持久性：一旦事务提交，修改会永久保存。
事务日志可以提高事务的效率，在数据修改时，只需要将修改行为以追加方式持久化到事务日志中。然后在后台，慢慢将事务日志中的数据修改刷回到磁盘中。
隔离级别： 事务的隔离性，比想象中要复杂。
未提交读（READ UNCOMMITTED）：一个事务所有做的修改在未提交之前，对其他事务也是可见的。事务可以读取未提交的数据，这也称为脏读。
提交读（READ COMMONTTED） ： 一个事务所有做的修改在未提交之前，对其他事务是不可见的。这个级别也叫做不可重复读，因为多次同样的查询可能会得到不一样的结果。
可重复读（REPEATABLE READ）：它是mysql默认隔离级别。该级别保证了多次查询结果的一致性。但还是无法解决幻读问题。
可串行化（SERIALIZABLE）：它是最高隔离级别，通过强制事务串行执行，从而避免幻读问题。
死锁：当多个事务相互请求对方占用的资源时，相互等待资源释放，从而导致恶性循环的现象。死锁产生有双重原因：有些是因为真正的数据冲突，这种情况很难避免，但有些则完全是由于存储引擎实现方式导致的。
mysql 事务是由存储引擎实现的，所以在同一事务中，使用多种存储引擎是不可靠的。例如：在事务中同时使用了事务型和非事务型的表，在成功提交时没问题，但失败时，就无法全部回滚了。
mysql 默认采用自动提交模式，也就是说，如果不是显示地开始一个事务，则条查询语句都被当作一个事务执行提交操作。
在事务执行过程中，随时都可以执行锁定，锁只有在执行提交或回滚的时候，才会被释放。InnoDB 会根据隔离级别在需要的时候自动加锁。
查询插入、更新、删除时，会自动加销，而查询要显示加锁。
select * from table where ? lock in share mode;
select * from table where ? for update;
多版本并发控制（MVCC）：它是行级锁的一个变种，它在很多情况下避免了加锁操作，实现了非阻塞读操作，提升了并发性。不同存储引擎的MVCC实现是不同的，典型的有乐观并发控制和悲观并发控制。
悲观并发控制：它假设在多用户并发的事务处理时很容易互相影响，因而采取一种“先取锁再访问”的保守策略，为数据处理的安全提供了保证。悲观并发控制主要用于数据争用激烈的环境，以及发生并发冲突时使用锁保护数据的成本要低于回滚事务的成本的环境中。
乐观并发控制：它假设多用户并发的事务在处理时不会互相影响，各事务能够在不产生锁的情况下，处理各自影响的那部分数据。在提交数据更新之前，每个事务会先检查在该事务读取数据后，有没有其他事务又修改了该数据。如果其他事务有更新的话，正在提交的事务会进行回滚。乐观并发控制多数用于数据争用不大、冲突较少的环境中。这种环境中，偶尔回滚事务的成本会低于读取数据时锁定数据的成本，因此可以获得比其他并发控制方法更高的吞吐量。
MyISAM存储引擎：如果一张表中的数据，创建之后，一般不再修改，那么种这表或许适合采用MyISAM存储引擎。MyISAM引擎设计简单，数据以紧密格式存储，所以在某些场景下的性能很好。
选择适合的存储引擎：大多数情况下，InnoDB都是正确的选择。如果需要应用不同的存储引擎，则要考虑到以下几个因素：事务，备份，崩溃恢复，独有特性。
mysql 数据类型： mysql 支持的数据类型非常多，选择正确的数据类型对于获得高性能至关重要。
更小的通常理好：一般情况应该尽量使用可以正确存储数据的最小数据类型。更小的数据类型通常更快。如:保存字符串的可以用 char,varchar,text等,那么优先选择char和varchar
简单就好： 简单数据类型的操作通常需要更少的CPU周期。例如：整型比字符串操作代价更低。
尽量避免NULL：查询中包含可为NULL的列会占用更多存储空间。同时，它也使得索引、索引统计和值比较，都更为复杂。
数据库的优化可以从四个方面来优化
1.从架构层: web服务器采用负载均衡服务器,mysql服务器采用主从复制,读写分离
2.从储存层: 采用合适的数据类型，存储引擎,采用三范式
3.从设计层: 采用分区分表,索引,表的字段采用合适的字段属性,适当的采用逆范式,开启mysql缓存
4.sql语句层:结果一样的情况下,采用效率高,速度快节省资源的sql语句执行
SQL语句优化有哪些方法
1）Where子句中：where表之间的连接必须写在其他Where条件之前，那些可以过滤掉最大数量记录的条件必须写在Where子句的末尾.HAVING最后。
2）用EXISTS替代IN、用NOT EXISTS替代NOT IN。
3） 避免在索引列上使用计算
4）避免在索引列上使用IS NULL和IS NOT NULL
5）对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。
6）应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描
7）应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描
开启慢查询日志：
#开启慢查询日志
set global slow_query_log = on;
#设置慢查询日志文件路径
set global slow_query_log_file = ‘e:\warehouse\mysql-slow.log‘;
#是否记录未使用索引的sql语句
set global log_queries_not_using_indexes = on;
#慢查询时间长度
set global long_query_time = 0;
#查看设置后的结果
show variables like ‘slow_query_log‘;
show variables like ‘log_queries_not_using_indexes‘;
show variables like ‘slow_query_log_file‘;
show variables like ‘long_query_time‘;
#执行一些sql语句
SELECT * FROM address limit 110;
标签：time sql语句 三范式 比较 取数据 存储引擎 不可 har 区分
原文地址：https://www.cnblogs.com/zbseoag/p/9898713.html
