From fbc0a1e837d519b7a66b4efa2375496973b7a6a1 Mon Sep 17 00:00:00 2001 From: Keqi Huang Date: Wed, 8 Aug 2018 11:59:34 +0800 Subject: [PATCH 1/4] =?UTF-8?q?=E5=A2=9E=E5=8A=A0=E4=B8=80=E4=BA=9B?= =?UTF-8?q?=E6=95=B0=E6=8D=AE=E5=BA=93=E6=95=B0=E6=8D=AE=E8=AE=BF=E9=97=AE?= =?UTF-8?q?=E6=96=B9=E9=9D=A2=E7=9A=84=E4=BC=98=E5=8C=96=E6=96=B9=E6=B3=95?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- notes/MySQL.md | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+) diff --git a/notes/MySQL.md b/notes/MySQL.md index 690425db..f2949801 100644 --- a/notes/MySQL.md +++ b/notes/MySQL.md @@ -304,6 +304,60 @@ Explain 用来分析 SELECT 查询语句，开发人员可以通过分析 Explai 最有效的方式是使用索引来覆盖查询。 +### 3. 不要在列上使用函数和进行运算 + +在列上使用函数和计算将导致索引失效而进行全表扫描。 + +### 4. 尽量避免使用 != 或 not in 或 <> 等否定操作符 + +尽量避免在 where 子句中使用 or 来连接条件，因为这会导致索引失效而进行全表扫描。 + +### 5. 尽量避免使用 or 来连接条件 + +尽量避免在 where 子句中使用 or 来连接条件，因为这会导致索引失效而进行全表扫描。 + +### 6. 多个单列限制应该改成一个多列索引（复合索引）查询 + +因为 MySQL 只能使用一个单列索引，所以为多个列创建单列索引并不能提高 MySQL 的查询性能。正确的做法是将这多个要限定条件的列单独做成一个多列索引（复合索引）。 + +### 7. 查询时要按照复合索引的最左列开始查找 + +查询条件中没有使用复合索引的第一个字段，索引是不会被使用的。复合索引遵守“最左前缀”原则，即在查询条件中使用了复合索引的第一个字段，索引才会被使用。 + +假如我们只有一个复合索引 ```age_height_idx(age, height)``` + +如果我们使用 +```mysql +select * from user where height = 170; +``` +那么复合索引 ```age_height_idx(age, height)```将不会被使用。 + +### 8. 尽量不用范围查询 + +如果查询中的某个列有范围查询，则其右边所有列都无法使用索引优化查找。 + +比如说我们使用 +```mysql +select * from users where age > 16 and age < 30 and height = 180 +``` +则索引中 age 右边所有列都无法使用索引优化查找。换句话说，```age_height_idx(age, height)``` 索引等价于 ```age_height_idx(age)```。 + +### 9. 索引不要包含有NULL值的列 + +只要列中包含有 NULL 值，它就不会被包含在索引中，复合索引中只要有一列含有 NULL 值，那么这一列对于此复合索引就是无效的。 + +因此，在数据库设计时，除非有一个很特别的原因使用 NULL 值，不然尽量不要让字段的默认值为 NULL。 + +### 10. 隐式转换可能带来不好的影响 + +当 where 查询条件左右两侧类型不匹配的时候会发生隐式转换，隐式转换可能带来的不好影响就是导致索引失效而进行全表扫描。 + +下面的案例中，brith_date 是字符串，然而匹配的是整数类型，从而发生隐式转换。 + +```mysql +select from users where brith_date = 19950610; +``` + ## 重构查询方式 ### 1. 切分大查询 From 30d980c04fb91efc5a348aef1faa92e313d16233 Mon Sep 17 00:00:00 2001 From: Keqi Huang Date: Wed, 8 Aug 2018 12:04:42 +0800 Subject: [PATCH 2/4] Update MySQL.md --- notes/MySQL.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/notes/MySQL.md b/notes/MySQL.md index f2949801..e49087bf 100644 --- a/notes/MySQL.md +++ b/notes/MySQL.md @@ -358,6 +358,10 @@ select * from users where age > 16 and age < 30 and height = 180 select from users where brith_date = 19950610; ``` +### 11. like 语句的索引失效问题 + +当我们使用 like “value%” 的方式时是会使用索引的，但是对于 like “%value%” 这样的方式，必定会执行全表查询，这在数据量小的表，不存在性能问题，但是对于海量数据，全表扫描是非常可怕的事情。所以，根据业务需求，考虑使用 ElasticSearch 或 Solr 是个不错的方案。 + ## 重构查询方式 ### 1. 切分大查询 From 93a9fe11cb2b2c626206e5276132b1bc1961814a Mon Sep 17 00:00:00 2001 From: Keqi Huang Date: Wed, 8 Aug 2018 12:51:18 +0800 Subject: [PATCH 3/4] Update MySQL.md --- notes/MySQL.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/notes/MySQL.md b/notes/MySQL.md index e49087bf..02dbe638 100644 --- a/notes/MySQL.md +++ b/notes/MySQL.md @@ -483,3 +483,5 @@ MySQL 读写分离能提高性能的原因在于： - [How to create unique row ID in sharded databases?](https://stackoverflow.com/questions/788829/how-to-create-unique-row-id-in-sharded-databases) - [SQL Azure Federation – Introduction](http://geekswithblogs.net/shaunxu/archive/2012/01/07/sql-azure-federation-ndash-introduction.aspx "Title of this entry.") - [MySQL 索引背后的数据结构及算法原理](http://blog.codinglabs.org/articles/theory-of-mysql-index.html) +- [服务端指南 数据存储篇 | MySQL（04） 索引使用的注意事项](http://blog.720ui.com/2017/mysql_core_04_index_item/) +- [mysql 聚簇索引 和聚簇索引 （二级索引）的 那些事](https://blog.csdn.net/bigtree_3721/article/details/51335479) From 4b0db3f578c0414fe29847a7e70d56f557789745 Mon Sep 17 00:00:00 2001 From: Keqi Huang Date: Wed, 8 Aug 2018 14:10:19 +0800 Subject: [PATCH 4/4] =?UTF-8?q?Update=20=E6=95=B0=E6=8D=AE=E5=BA=93?= =?UTF-8?q?=E7=B3=BB=E7=BB=9F=E5=8E=9F=E7=90=86.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- notes/数据库系统原理.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/notes/数据库系统原理.md b/notes/数据库系统原理.md index 151ffc0f..6b8fcd86 100644 --- a/notes/数据库系统原理.md +++ b/notes/数据库系统原理.md @@ -389,11 +389,11 @@ MVCC 不能解决幻读的问题，Next-Key Locks 就是为了解决这个问题 ## Gap Locks -锁定一个范围内的索引，例如当一个事务执行以下语句，其它事务就不能在 t.c 中插入 15。 +间隙锁锁住的是多行，是一个数据范围。间隙锁主要是为了防止出现幻读，但是它会把锁定范围扩大，有时候也会给我们带来麻烦。在数据库参数中，控制间隙锁的参数是 ```innodb_locks_unsafe_for_binlog```， 这个参数默认值是 OFF，也就是启用间隙锁，它是一个bool值，当值为 true 时表示 disable 间隙锁。那为了防止间隙锁是不是直接将 ```innodb_locaks_unsafe_for_binlog``` 设置为 ```true``` 就可以了呢？不一定！而且这个参数会影响到主从复制及灾难恢复，这个方法还尚待商量。 -```sql -SELECT c FROM t WHERE c BETWEEN 10 and 20 FOR UPDATE; -``` +间隙锁的出现主要集中在同一个事务中先 delete 后 insert 的情况下，当我们通过一个参数去删除一条记录的时候，如果参数在数据库中存在，那么这个时候产生的是普通行锁，锁住这个记录，然后删除，最后释放锁。如果这条记录不存在，问题就来了，数据库会扫描索引，发现这个记录不存在，这个时候的 delete 语句获取到的就是一个间隙锁，然后数据库会向左扫描扫到第一个比给定参数小的值，向右扫描扫描到第一个比给定参数大的值，然后以此为上下界限构建一个区间，进而锁住整个区间内的数据，一个特别容易出现死锁的间隙锁诞生了。 + +通过修改 ```innodb_locaks_unsafe_for_binlog``` 参数来取消间隙锁从而达到避免这种情况的死锁的方式尚待商量，那就只有修改代码逻辑，存在才删除，尽量避免去删除不存在的记录。 ## Next-Key Locks