一篇文章掌握MySQL的索引查询优化技巧

前言

本文的内容是总结一些MySQL的常见使用技巧,以供没有DBA的团队参考。如无特殊说明,存储引擎以InnoDB为准。

MySQL的特点

了解MySQL的特点有助于更好的使用MySQL,MySQL和其它常见数据库最大的不同在于存在存储引擎这个概念,存储引擎负责存储和读取数据。不同的存储引擎具有不同的特点,用户可以根据业务的特点选择适合的存储引擎,甚至是开发一个新的引擎。MySQL的逻辑架构大致如下:

MySQL默认的存储引擎是InnoDB,该存储引擎的主要特点是:

  • 支持事务处理
  • 支持行级锁
  • 数据存储在表空间中,表空间由一些列数据文件组成
  • 采用MVVC(多版本并发控制)机制实现高并发
  • 表基于主键的聚簇索引建立
  • 支持热备份

其它常见存储引擎特点概述:

  • MyISAM:老版本MySQL的默认引擎,不支持事务和行级锁,开发者可以手动控制表锁;支持全文索引;崩溃后无法安全恢复;支持压缩表,压缩表数据不可修改,但占用空间较少,可以提高查询性能
  • Archive:只支持Insert和Select,批量插入很快,通过全表扫描查询数据
  • SCV:把一个SCV文件当做一个表处理
  • Memory:数据存储在内存中

还有很多,不再一一列举。

数据类型优化

选择数据类型的原则:

  • 选择占用空间小的数据类型
  • 选择简单的类型
  • 避免不必要的可空列

占用空间小的类型更节省硬件资源,如磁盘、内存和CPU。尽量使用简单的类型,如能用 int 就不用 char ,因为后者的排序涉及到字符集的选择,比使用 int 复杂。可空列使用更多的存储空间,如果在可空列上创建索引,MySQL需要额外的字节做记录。创建表时,默认都是可空,容易被开发者忽视,最好是手动改为不可空,如果要存储的数据确实不会有空值的话。

整型类型

整型类型包括 :

  • tinyint
  • smallint
  • mediumint
  • int
  • bigint

它们分别使用8、16、24、32和64位存储数字,它们可以表示

范围的数字,前面可以加unsigned修饰,这样可以让正数的可表示范围提高1倍,但是无法表示负数。另外,为整型指定长度没什么卵用,数据类型定下来,长度也就相应定下来了。

小数类型

  • float
  • double
  • decimal

float 和 double 就是通常意义上的 float 和 double ,前者使用32位存储数据,后者使用64位存储数据,和整型一样,为它们指定长度没什么卵用。

decimal 类型比较复杂,支持精确计算,占用的空间也大, decimal 使用每4个字节表示9个数字,如 decimal(18,9) 表示数字长度是18,其中小数位9个数字,整数部分9个数字,加上小数点本身,共占用9个字节。考虑到 decimal 占用空间较多,以及精度计算很复杂,数据量大的时候可以考虑用 bigint 代替之,可以在持久化和读取前对真实数据进行一些缩放操作。

字符串类型

  • varchar
  • char
  • varbinary
  • binary
  • blob
  • text
  • 枚举

varchar类型数据实际占用空间等于字符串的长度加上1个或2个用来记录字符串长度的字节(当row-format没有被设置为fixed时),varchar很节省空间。当表中某列字符串类型的数据长度差别较大时适合使用varchar。

char的实际占用空间是固定的,当表中字符串数据的长度相差无几或很短时适合使用chart类型。

与varchar和char对应的有varbinary和binary,后者存储的是二进制字符串,和前者相比,后者大小写敏感,不用考虑编码方式,执行比较操作时更快。

需要注意的是:虽然varchar(5)和varchar(200)在存储“hello”这个字符串时使用相同的存储空间,但并不意味着将varchar的长度设置太大不会影响性能,实际上,MySQL的某些内部计算,比如创建内存临时表时(某些查询会导致MySQL自动创建临时表),会分配固定大小的空间存放数据。

blob使用二进制字符串保存大文本,text使用字符保存大文本,InnoDB会使用专门的外部存储区来存放此类数据,数据行内仅存放指向他们的指针,此类数据不宜创建索引(要创建也只能正对字符串前缀创建),不过也不会有人这么干。

如果某列字符串大量重复且内容有限,可使用枚举代替,MySQL处理枚举时维护了一个“数字-字符串”表,使用枚举可以减少很多存储空间。

时间类型

  • year
  • date
  • time
  • datetime
  • timestamp

datetime存储范围是1001到9999,精确到秒。timestamp存储1970年1月1日午夜以来的秒数,可以表示到2038年。占用4个字节,是datetime占用空间的一半。timestamp表示的时间和时区有关,另外timestamp列还有个特性,执行insert或update语句时,MySQL会自动更新第一个类型为timestamp的列的数据为当前时间。很多表中都有设计有一列叫做UpdateTime,这个列使用timestamp倒是挺合适的,会自动更新,前提是系统不会使用到2038年。

主键类型的选择

尽可能使用整型,整型占用空间少,还可以设置为自动增长。尤其别使用GUID,MD5等哈希值字符串作为主键,这类字符串随机性很大,由于InnoDB主键默认是聚簇索引列,所以导致数据存储太分散。另外,InnoDB的二级索引列中默认包含主键列,如果主键太长,也会使得二级索引很占空间。

特殊类型的数据

存储IP最好使用32位无符号整型,MySQL提供了函数inet_aton()和inet_ntoa()进行IP地址的数字表示和字符串表示之间的转换。

索引优化

InnoDB使用B+树实现索引,举个例子,假设有个People,建表语句如下

CREATE TABLE `people` (
 `Id` int(11) NOT NULL AUTO_INCREMENT,
 `Name` varchar(5) NOT NULL,
 `Age` tinyint(4) NOT NULL,
 `Number` char(5) NOT NULL COMMENT '编号',
 PRIMARY KEY (`Id`),
 KEY `i_name_age_number` (`Name`,`Age`,`Number`)
) ENGINE=InnoDB AUTO_INCREMENT=14 DEFAULT CHARSET=utf8;

插入数据:

它的索引结构大致是这样的:

也就是说,索引列的顺序很重要,如果两行数据的Name列相同,则用Age列比较大小,如果Age列相同,则用Number列比较大小。先用第一列排序,然后是第二列,最后是第三列。

查询的使用应该尽量从左往右匹配,另外,如果左边列范围查找,右边列无法使用索引;还有就是不能隔列查询,否则后面的索引也无法使用到。如以下几个SQL是正面范例:

  • SELECT * from people where Name ='Abel' and Age = 2 AND Number = 12312
  • SELECT * from people where Name ='Abel'
  • SELECT * from people where Name like ‘Abel%'
  • SELECT * from people where Name = ‘Andy' and Age BETWEEN 11 and 20
  • SELECT * from people ORDER BY NAME
  • SELECT * from people ORDER BY NAME, Age
  • SELECT * from people GROUP BY Name

以下几个SQL是反面范例:

  • SELECT * from people where Age = 2
  • SELECT * from people where NAME like ‘%B'
  • SELECT * from people where age = 2
  • SELECT * from people where NAME = ‘ABC' AND number = 3
  • SELECT * from people where NAME like ‘B%' and age = 22

一个使用Hash值创建索引的技巧

如果表中有一列存储较长字符串,假设名字为URL,在此列上创建的索引比较大,有个办法可以缓解:创建URL字符串的数字哈希值的索引。再新建一个字段,比如叫做URL_CRC,专门放置URL的哈希值,然后给这个字段创建索引,查询时这样写:

select * from t where URL_CRC = 387695885 and URL = 'www.baidu.com'

如果数据量比较多,为防止哈希冲突,可自定义哈希函数,或用MD5函数返回值的一部分作为哈希值:

SELECT CONV(RIGHT(MD5('www.baidu.com'),16), 16, 10)

前缀索引

如果字符串列存储的数据较长,创建的索引也很大,这时可以使用前缀索引,即:只针对字符串前几个字符做索引,这样可以缩短索引的大小,不过,显然,此类索引在执行 order by 和 group by 时不起作用。

创建前缀索引时选择前缀长度很重要,在不破坏原来数据分布的情况下尽可能选择较短的前缀。举个例子,如果如果大部分字符串是以”abc”开头,那么如果限定前缀索引长度为4,索引值会包含太多的重复的”abcX”。

多列索引

上面提到的“People”上创建的索引即为多列索引,多列索引往往比多个单列索引更好。

  • 对多个索引进行and查询时,应该创建多列索引,而不是多个单列索引
  • 可以试试这样写的效果:
select * from t where f1 = 'v1' and f2 <> 'v2' union all select * from t where f2 = 'v2' and f1 <> 'v1'

多列索引的顺序很重要,通常,不考虑排序和分组查询时,应该把选择性(选择性是指某表索引列不同数据的个数/总行数。选择性高意味着重复数据少)大的列放到前面。但也有例外,如果能确认某些查询是频繁执行的,则应该优先照顾这些查询的选择性,比如,如果上面的People表中Name的选择性大于Age,查询语句应该这样写:

select * from people where name = 'xxx' and age = xx

Name列放了索引中的左侧比较合适,但是如果某个SQL执行的评率最高,比如

select * from people where name = 'xxx' and age = 20

当age=20的记录在数据库中非常少时,反而把age放到索引列的左端效率更高。把age放了索引左端可能对其它age不等于20的查询来说不公平,如果不能确定age=20是最非常频繁的查询条件,还是要综合考虑,把name放了左侧合适。

聚簇索引

聚簇索引是一种数据存储结构,InnoDB在主键的索引的叶子节点中直接保存了数据行,而不是像二级索引那样只是保存了索引列的值和所指向行的主键值。由于这个特性,一个表只能有一个聚簇索引。如果一个表没有定义主键也没有定义具有唯一索引的列,那么InnoDB会生成一个隐藏列,并且在此列设为聚簇索引列。

覆盖索引

简单地说,某些查询只需要查询索引列,那么就不用再根据索引B树节点记录的主键ID进行二次查询了。

重复索引和冗余索引

如果重复在某列创建索引,并不会带来任何好处,只有坏处,应该尽量避免。比如给主键创建唯一索引和普通索引就是多于的,因为InnoDB的主键默认就是聚簇索引了。

冗余索引和重复索引不同,比如某个索引是(A,B),另一个索引是(A),这叫冗余索引,前者可以代替后者,后者不可以代替前者的作用。但是(A,B)和(B)以及(A,B)和(B,A)不算冗余索引,起作用谁也代替不了谁。

如果一个表中已经存在索引(A),现在又想创建索引(A,B),那么只需扩展就的索引就可以,没有必要创建新的索引。需要注意的是如果已经存在索引(A),那么也没有必要在创建索引(A,ID),其中ID指主键,因为索引A默认已经包含了主键了,也算是冗余主键。

但是,有时候,冗余索引也是可取的,假设已经存在索引(A),将其扩展为(A,B)后,因为B列是一个很长的类型,导致用A单独查询时没有以前快了,这时可以考虑新创建索引(A,B)。

不使用的索引

不使用的索引徒然增加insert、update和delete的效率,应该及时删除

索引使用总结

索引的三星原则:

  • 索引将查询相关的记录按顺序放在一起则得一星
  • 索引中的数据顺序和查询结果的排序一致则得一星
  • 索引中包含了查询所需要的全部列则得一星

第一个条原则的意思是where条件中查询的顺序和索引是一致的,就是前面说的从左到右使用索引。

索引不是万能的,当数据量巨大时,维护索引本身也是耗费性能的,应该考虑分区分表存储。

查询优化

查询慢的原因

是否向数据库请求了多余的行

比如应用程序只需要10条数据,但是却向数据库请求了所有的数据,在显示在UI上之前抛弃了大部分数据。

是否向数据库请求了多余的列

比如应用程序只需要展现5列,但却通过select * from 把全部的列都查了出来

是否重复多次执行了相同的查询

应用程序是否可以考虑一次查询然后缓存,后面的用到时可以使用第一次查询出来的记录。

MySQL是否在扫描额外的记录

通过查看执行计划可以大概了解需要扫描的记录数,如果这个数字超出了预期,尽可能通过添加索引、优化SQL(就是本节的重点),或者改变表结构(如新增一个单独的汇总表,专门供某个语句查询用)来解决。

重构查询的方式

  • 将一个复杂的查询分解成多个简单的查询
  • 将大的查询切分成小的查询,每次查询功能一样,只完成一小部分
  • 分解关联查询。可以将一个大的关联查询改成分别查询若干个表,然后在应用程序代码中处理

杂七杂八

优化count()

Count有两个作用,一是统计指定的列或表达式,二是统计行数。如果参数传入一列名或者是一个表达式,那么count会统计所有结果不为NULL的行数,如果参数是*,那么count会统计所有行数。这里有一个传表达式的例子:

SELECT count(name like 'B%') from people
  • 可以使用近似值优化来代替count(),如执行计划中的行数。
  • 索引覆盖扫描
  • 增加汇总表
  • 增加内存缓存系统记录数据条数

关联查询的优化

  • MySQL优化器关联表查询是这样进行的,比如有两个表A和B通过c列关联,MySQL会遍历A表,然后根据遍历到的c列的值去B表中查找数据。综上所述,通常,如无只需要给B表的c列加上索引即可
  • 确保order by和group by涉及到的列只属于一个表,这样才有可能发挥索引的作用

优化子查询

对于MySQL5.5及以下版本,尽量用连接代替子查询。

优化group by、distinct

如果可能,尽量对主键施加这两种操作。

优化limit,比如有SQL

SELECT * from sa_stockinfo ORDER BY StockAcc LIMIT 400, 5

MySQL优化器会查找405行所有列数据然后丢弃400。如果能利用覆盖索引查询则不必查询出这么多列,先修改为:

SELECT * FROM sa_stockinfo i JOIN (SELECT StockInfoID FROM sa_stockinfo ORDER BY StockAcc LIMIT 400,5)t ON i.StockInfoID = t.StockInfoID

StockAcc上建有索引,该查询会利用索引覆盖,较快找出符合条件的主键,然后在做联合查询,在数据量大的时候效果明显。

优化union

如无必要,一定要用关键字 union all,这样MySQL把数据放到临时表时不会再做唯一性验证

判断某条记录是否存在,通常的做法是

select count(*) from t where condition

最好这样写:

SELECT IFNULL((SELECT 1 from tableName where condition LIMIT 1),0)

总结

到此这篇关于MySQL索引查询优化技巧的文章就介绍到这了,更多相关MySQL索引查询优化技巧内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • MySQL 索引分析和优化

    一.什么是索引? 索引用来快速地寻找那些具有特定值的记录,所有MySQL索引都以B-树的形式保存.如果没有索引,执行查询时MySQL必须从第一个记录开始扫描整个表的所有记录,直至找到符合要求的记录.表里面的记录数量越多,这个操作的代价就越高.如果作为搜索条件的列上已经创建了索引,MySQL无需扫描任何记录即可迅速得到目标记录所在的位置.如果表有1000个记录,通过索引查找记录至少要比顺序扫描记录快100倍. 假设我们创建了一个名为people的表: CREATE TABLE people ( p

  • MySQL 联合索引与Where子句的优化 提高数据库运行效率

    网站系统上线至今,数据量已经不知不觉上到500M,近8W记录了.涉及数据库操作的基本都是变得很慢了,用的人都会觉得躁火~~然后把这个情况在群里一贴,包括机器配置什么的一说,马上就有群友发话了,而且帮我确定了不是机器配置的问题,"深圳-枪手"热心人他的机器512内存过百W的数据里也跑得飞快,甚至跟那些几W块的机器一样牛(吹过头了),呵呵~~~ 在群友的分析指点下,尝试把排序.条件等一个一个去除来做测试,结果发现问题就出在排序部分,去除排序的时候,执行时间由原来的48秒变成0.3x秒,这是

  • MySQL中索引优化distinct语句及distinct的多字段操作

    MySQL通常使用GROUPBY(本质上是排序动作)完成DISTINCT操作,如果DISTINCT操作和ORDERBY操作组合使用,通常会用到临时表.这样会影响性能. 在一些情况下,MySQL可以使用索引优化DISTINCT操作,但需要活学活用.本文涉及一个不能利用索引完成DISTINCT操作的实例. 实例1 使用索引优化DISTINCT操作 create table m11 (a int, b int, c int, d int, primary key(a)) engine=INNODB;

  • MySQL索引背后的之使用策略及优化(高性能索引策略)

    本章的内容完全基于上文的理论基础,实际上一旦理解了索引背后的机制,那么选择高性能的策略就变成了纯粹的推理,并且可以理解这些策略背后的逻辑. 示例数据库 为了讨论索引策略,需要一个数据量不算小的数据库作为示例.本文选用MySQL官方文档中提供的示例数据库之一:employees.这个数据库关系复杂度适中,且数据量较大.下图是这个数据库的E-R关系图(引用自MySQL官方手册): 图12 MySQL官方文档中关于此数据库的页面为http://dev.mysql.com/doc/employee/en

  • MySQL Order By索引优化方法

    尽管 ORDER BY 不是和索引的顺序准确匹配,索引还是可以被用到,只要不用的索引部分和所有的额外的 ORDER BY 字段在 WHERE 子句中都被包括了. 使用索引的MySQL Order By 下列的几个查询都会使用索引来解决 ORDER BY 或 GROUP BY 部分: 复制代码 代码如下: SELECT * FROM t1 ORDER BY key_part1,key_part2,... ; SELECT * FROM t1 WHERE key_part1=constant ORD

  • Mysql使用索引实现查询优化

    索引的目的在于提高查询效率,可以类比字典,如果要查"mysql"这个单词,我们肯定需要定位到m字母,然后从下往下找到y字母,再找到剩下的sql.如果没有索引,那么你可能需要把所有单词看一遍才能找到你想要的. 1.索引的优点 假设你拥有三个未索引的表t1.t2和t3,每个表都分别包含数据列i1.i2和i3,并且每个表都包含了1000条数据行,其序号从1到1000.查找某些值匹配的数据行组合的查询可能如下所示: SELECT t1.i1, t2.i2, t3.i3 FROM t1, t2,

  • 探究MySQL优化器对索引和JOIN顺序的选择

    本文通过一个案例来看看MySQL优化器如何选择索引和JOIN顺序.表结构和数据准备参考本文最后部分"测试环境".这里主要介绍MySQL优化器的主要执行流程,而不是介绍一个优化器的各个组件(这是另一个话题). 我们知道,MySQL优化器只有两个自由度:顺序选择:单表访问方式:这里将详细剖析下面的SQL,看看MySQL优化器如何做出每一步的选择. explain select * from employee as A,department as B where A.LastName = '

  • MySQL优化GROUP BY(松散索引扫描与紧凑索引扫描)

    满足GROUP BY子句的最一般的方法是扫描整个表并创建一个新的临时表,表中每个组的所有行应为连续的,然后使用该临时表来找到组并应用累积函数(如果有).在某些情况中,MySQL能够做得更好,即通过索引访问而不用创建临时表.        为GROUP BY使用索引的最重要的前提条件是所有GROUP BY列引用同一索引的属性,并且索引按顺序保存其关键字.是否用索引访问来代替临时表的使用还取决于在查询中使用了哪部分索引.为该部分指定的条件,以及选择的累积函数.        由于GROUP BY 实

  • mysql性能优化之索引优化

    作为免费又高效的数据库,mysql基本是首选.良好的安全连接,自带查询解析.sql语句优化,使用读写锁(细化到行).事物隔离和多版本并发控制提高并发,完备的事务日志记录,强大的存储引擎提供高效查询(表记录可达百万级),如果是InnoDB,还可在崩溃后进行完整的恢复,优点非常多.即使有这么多优点,仍依赖人去做点优化,看书后写个总结巩固下,有错请指正. 完整的mysql优化需要很深的功底,大公司甚至有专门写mysql内核的,sql优化攻城狮,mysql服务器的优化,各种参数常量设定,查询语句优化,主

  • 一篇文章掌握MySQL的索引查询优化技巧

    前言 本文的内容是总结一些MySQL的常见使用技巧,以供没有DBA的团队参考.如无特殊说明,存储引擎以InnoDB为准. MySQL的特点 了解MySQL的特点有助于更好的使用MySQL,MySQL和其它常见数据库最大的不同在于存在存储引擎这个概念,存储引擎负责存储和读取数据.不同的存储引擎具有不同的特点,用户可以根据业务的特点选择适合的存储引擎,甚至是开发一个新的引擎.MySQL的逻辑架构大致如下: MySQL默认的存储引擎是InnoDB,该存储引擎的主要特点是: 支持事务处理 支持行级锁 数

  • 一篇文章学会MySQL基本查询和运算符

    目录 MySQL基本查询 查询概念: 1.查询所有商品: 2.查询某列: 3.别名查询: 4.列别名查询: 5.去重复值查询: 6.查询结果是表达式--运算查询 运算符 1.将所以商品价格上调10%: 2.查询商品名为“海尔洗衣机”的商品的信息 3.查询价格是200或800的所以商品: 4.like-----通配符匹配 5.NULL的使用: 6.函数的使用: 总结 MySQL基本查询 查询概念: 查询是数据库管理系统中一个重要功能,数据查询不应只是简单返回数据库中存储的信息 还应该根据需要对数据

  • 一篇文章讲解清楚MySQL索引

    目录 一丶什么是索引 二丶索引的数据结构 1.哈希表 2.有序数组 3.跳表 4.平衡二叉搜索树 5.B-树,B+树 三丶InnoDB索引方案 1.InnoDB行结构 2.InnoDB页结构 2.1行结构中记录头信息的作用 2.2页目录 3.InnoDB索引方案 3.1为页建立目录项 3.2 根据目录项定位数据行的过程 三丶聚集索引和非聚集索引 四丶回表查询 五丶联合索引 六丶索引与排序和分组 1.索引用于排序 2.索引用于分组 七丶多范围读取MRR 八丶索引合并 1.交集索引合并 2.并集索引

  • 一篇文章带你掌握MySQL索引下推

    目录 1.什么是索引下推 2.案例 2.1.MySQL5.5版本 2.2.MySQL5.7版本 3.小结 1.什么是索引下推 索引下推(Index Condition PushDown,简称ICP)是从MySQL5.6开始引入的一个特性,索引下推通过减少回表的次数来提高数据库的查询效率; 2.案例 准备: ①.为了演示索引下推,需要安装MySQL5.5和MySQL5.7两个版本的MySQL,因为索引下推是MySQL5.6版本中开始引入的新特性,所以这两个版本就可以演示出索引下推的特点; ②.数据

  • MySQL的索引原理以及查询优化详解

    目录 一.介绍 1.什么是索引? 2.为什么要有索引呢? 二.索引的原理 一 索引原理 二 磁盘IO与预读 三.索引的数据结构 四.Mysql索引管理 一.功能 二.MySQL的索引分类 三. 索引的两大类型hash与btree 四.创建/删除索引的语法 五.测试索引 1.准备 2 .在没有索引的前提下测试查询速度 3. 加上索引 六.正确使用索引 一.覆盖索引 二.联合索引 三.索引合并 七.慢查询优化的基本步骤 总结 一.介绍 1.什么是索引? 一般的应用系统,读写比例在10:1左右,而且插

  • 30个mysql千万级大数据SQL查询优化技巧详解

    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 子句中使用!=或<>操作符,否则引擎将放弃使用

  • 一篇文章搞懂MySQL加锁机制

    目录 前言 锁的分类 乐观锁和悲观锁 共享锁(S锁)和排他锁(X锁) 按加锁粒度区分 全局锁 表级锁(表锁和MDL锁) 意向锁 行锁 间隙锁 next-key lock(临键锁) 加锁规则 死锁和死锁检测 总结 前言 在数据库中设计锁的目的是为了处理并发问题,在并发对资源进行访问时,数据库要合理控制对资源的访问规则. 而锁就是用来实现这些访问规则的一个数据结构. 在对数据并发操作时,没有锁可能会引起数据的不一致,导致更新丢失. 锁的分类 乐观锁和悲观锁 乐观锁: 对于出现更新丢失的可能性比较乐观

  • 一篇文章带你了解清楚Mysql 锁

    一丶为什么数据库需要锁 数据库锁设计的初衷是处理并发问题.作为多用户共享 的资源,当出现并发访问的时候,数据库需要合理地控制资源的访问规则.而锁就是用来实 现这些访问规则的重要数据结构. 根据加锁的范围,MySQL 里面的锁大致可以分成全局锁.表级锁和行锁三类 二丶全局锁&全库逻辑备份 全局锁就是对整个数据库实例加锁.全局锁的典型使用场景是,做全库逻辑备份,全库逻辑备份有以下几种方式: 1.Flush tables with read lock (FTWRL) Flush tables with

  • mysql索引使用技巧及注意事项

    一.索引的作用 一般的应用系统,读写比例在10:1左右,而且插入操作和一般的更新操作很少出现性能问题,遇到最多的,也是最容易出问题的,还是一些复杂的查询操作,所以查询语句的优化显然是重中之重. 在数据量和访问量不大的情况下,mysql访问是非常快的,是否加索引对访问影响不大.但是当数据量和访问量剧增的时候,就会发现mysql变慢,甚至down掉,这就必须要考虑优化sql了,给数据库建立正确合理的索引,是mysql优化的一个重要手段. 索引的目的在于提高查询效率,可以类比字典,如果要查"mysql

随机推荐