MySQL优化

方案概述 方案一:优化现有mysql数据库。优点:不影响现有业务,源程序不需要修改代码,成本最低。缺点:有优化瓶颈,数据量过亿就玩完了。
方案二:升级数据库类型,换一种100%兼容mysql的数据库。优点:不影响现有业务,源程序不需要修改代码,你几乎不需要做任何操作就能提升数据库性能,缺点:多花钱
方案三:一步到位,大数据解决方案,更换newsql/nosql数据库。优点:没有数据容量瓶颈,缺点:需要修改源程序代码,影响业务,总成本最高。以上三种方案,按顺序使用即可,数据量在亿级别一下的没必要换nosql,开发成本太高。三种方案我都试了一遍,而且都形成了落地解决方案。主要讲方案一

方案一详细说明:优化现有mysql数据库跟阿里云数据库大佬电话沟通 and Google解决方案 and 问群里大佬,总结如下(都是精华):

  • 1.数据库设计和表创建时就要考虑性能
  • 2.sql的编写需要注意优化
  • 3.分区
  • 4.分表
  • 5.分库

1.数据库设计和表创建时就要考虑性能

mysql数据库本身高度灵活,造成性能不足,严重依赖开发人员能力。也就是说开发人员能力高,则mysql性能高。这也是很多关系型数据库的通病,所以公司的dba通常工资巨高。

设计表时要注意:

  • 表字段避免null值出现,null值很难查询优化且占用额外的索引空间,推荐默认数字0代替null。
  • 尽量使用INT而非BIGINT,如果非负则加上UNSIGNED(这样数值容量会扩大一倍),当然能使用TINYINT、SMALLINT、MEDIUM_INT更好。
  • 使用枚举或整数代替字符串类型
  • 尽量使用TIMESTAMP而非DATETIME 单表不要有太多字段,建议在20以内
  • 用整型来存IP

索引

  • 索引并不是越多越好,要根据查询有针对性的创建,考虑在WHERE和ORDER BY命令上涉及的列建立索引,可根据EXPLAIN来查看是否用了索引还是全表扫描
  • 应尽量避免在WHERE子句中对字段进行NULL值判断,否则将导致引擎放弃使用索引而进行全表扫描
  • 值分布很稀少的字段不适合建索引,例如"性别"这种只有两三个值的字段
  • 字符字段只建前缀索引
  • 字符字段最好不要做主键
  • 不用外键,由程序保证约束 尽量不用UNIQUE,由程序保证约束
  • 使用多列索引时主意顺序和查询条件保持一致,同时删除不必要的单列索引

简言之就是使用合适的数据类型,选择合适的索引

1.选择合适的数据类型

  • (1)使用可存下数据的最小的数据类型,整型 < date,time < char,varchar < blob
  • (2)使用简单的数据类型,整型比字符处理开销更小,因为字符串的比较更复杂。如,int类型存储时间类型,bigint类型转ip函数
  • (3)使用合理的字段属性长度,固定长度的表会更快。使用enum、char而不是varchar
  • (4)尽可能使用not null定义字段
  • (5)尽量少用text,非用不可最好分表
    2.选择合适的索引列
  • (1)查询频繁的列,在where,group by,order by,on从句中出现的列
  • (2)where条件中<,<=,=,>,>=,between,in,以及like 字符串+通配符(%)出现的列
  • (3)长度小的列,索引字段越小越好,因为数据库的存储单位是页,一页中能存下的数据越多越好
  • (4)离散度大(不同的值多)的列,放在联合索引前面。查看离散度,通过统计不同的列值来实现,count越大,离散程度越高: 原开发人员已经跑路,该表早已建立,我无法修改,故:该措辞无法执行,放弃!

2.sql的编写需要注意优化

  • 使用limit对查询结果的记录进行限定
  • 避免select *,将需要查找的字段列出来
  • 使用连接(join)来代替子查询
  • 拆分大的delete或insert语句
  • 可通过开启慢查询日志来找出较慢的SQL
  • 不做列运算:SELECT id WHERE age + 1 = 10,任何对列的操作都将导致表扫描,它包括数据库教程函数、计算表达式等等,查询时要尽可能将操作移至等号右边
  • sql语句尽可能简单:一条sql只能在一个cpu运算;大语句拆小语句,减少锁时间;一条大sql可以堵死整个库
  • OR改写成IN:OR的效率是n级别,IN的效率是log(n)级别,in的个数建议控制在200以内
  • 不用函数和触发器,在应用程序实现
  • 避免%xxx式查询
  • 少用JOIN
  • 使用同类型进行比较,比如用’123’和’123’比,123和123比
  • 尽量避免在WHERE子句中使用!=或<>操作符,否则将引擎放弃使用索引而进行全表扫描
  • 对于连续数值,使用BETWEEN不用IN:SELECT id FROM t WHERE num BETWEEN 1 AND 5
  • 列表数据不要拿全表,要使用LIMIT来分页,每页数量也不要太大 原开发人员已经跑路,程序已经完成上线,我无法修改sql,故:该措辞无法执行,放弃!

引擎

目前广泛使用的是MyISAM和InnoDB两种引擎:

  1. MyISAMMyISAM引擎是MySQL 5.1及之前版本的默认引擎,它的特点是:
  • 不支持行锁,读取时对需要读到的所有表加锁,写入时则对表加排它锁
  • 不支持事务
  • 不支持外键
  • 不支持崩溃后的安全恢复
  • 在表有读取查询的同时,支持往表中插入新纪录
  • 支持BLOB和TEXT的前500个字符索引,支持全文索引
  • 支持延迟更新索引,极大提升写入性能
  • 对于不会进行修改的表,支持压缩表,极大减少磁盘空间占用
  1. InnoDBInnoDB在MySQL 5.5后成为默认索引,它的特点是:
  • 支持行锁,采用MVCC来支持高并发
  • 支持事务
  • 支持外键
  • 支持崩溃后的安全恢复
  • 不支持全文索引

总体来讲,MyISAM适合SELECT密集型的表,而InnoDB适合INSERT和UPDATE密集型的表

MyISAM速度可能超快,占用存储空间也小,但是程序要求事务支持,故InnoDB是必须的,故该方案无法执行,放弃!

3.分区

MySQL在5.1版引入的分区是一种简单的水平拆分,用户需要在建表的时候加上分区参数,对应用是透明的无需修改代码
对用户来说,分区表是一个独立的逻辑表,但是底层由多个物理子表组成,实现分区的代码实际上是通过对一组底层表的对象封装,但对SQL层来说是一个完全封装底层的黑盒子。MySQL实现分区的方式也意味着索引也是按照分区的子表定义,没有全局索引
用户的SQL语句是需要针对分区表做优化,SQL条件中要带上分区条件的列,从而使查询定位到少量的分区上,否则就会扫描全部分区,可以通过EXPLAIN PARTITIONS来查看某条SQL语句会落在那些分区上,从而进行SQL优化,我测试,查询时不带分区条件的列,也会提高速度,故该措施值得一试。
MySQL支持RANGE,LIST,HASH和KEY四种分区。其中,每个分区又都有一种特殊的类型。对于RANGE分区,有RANGE COLUMNS分区。对于LIST分区,有LIST COLUMNS分区。对于HASH分区,有LINEAR HASH分区。对于KEY分区,有LINEAR KEY分区。具体如下:

RANGE分区

RANGE即范围分区,根据区间来判断位于哪个分区,譬如,在下例中,如果store_id小于6,则新增或修改的记录会被分配到p0分区,如果大于6小于11,则记录会被分配到p1分区,依次类推。类似于编程语言中的if … elseif …语句。

格式如下:

复制代码

CREATE TABLE employees (
    id INT NOT NULL,
    fname VARCHAR(30),
    lname VARCHAR(30),
    hired DATE NOT NULL DEFAULT '1970-01-01',
    separated DATE NOT NULL DEFAULT '9999-12-31',
    job_code INT NOT NULL,
    store_id INT NOT NULL
)
PARTITION BY RANGE (store_id) (
    PARTITION p0 VALUES LESS THAN (6),
    PARTITION p1 VALUES LESS THAN (11),
    PARTITION p2 VALUES LESS THAN (16),
    PARTITION p3 VALUES LESS THAN MAXVALUE
);

注意:

  1. RANGE分区的返回值必须为整数。

  2. PARTITION p3 VALUES LESS THAN MAXVALUE 是非必需的。

RANGE COLUMNS分区

RANGE COLUMNS是RANGE分区的一种特殊类型,它与RANGE分区的区别如下:

  1. RANGE COLUMNS不接受表达式,只能是列名。而RANGE分区则要求分区的对象是整数。

  2. RANGE COLUMNS允许多个列,在底层实现上,它比较的是元祖(多个列值组成的列表),而RANGE比较的是标量,即数值的大小。

  3. RANGE COLUMNS不限于整数对象,date,datetime,string都可作为分区列。

格式如下:

CREATE TABLE rcx (
    a INT,
    b INT,
    c CHAR(3),
    d INT
)
PARTITION BY RANGE COLUMNS(a,d,c) (
    PARTITION p0 VALUES LESS THAN (5,10,'ggg'),
    PARTITION p1 VALUES LESS THAN (10,20,'mmmm'),
    PARTITION p2 VALUES LESS THAN (15,30,'sss'),
    PARTITION p3 VALUES LESS THAN (MAXVALUE,MAXVALUE,MAXVALUE)
);

同RANGE分区类似,它的区间范围必须是递增的,有时候,列涉及的太多,不好判断区间的大小,可采用下面的方式进行判断:

mysql> SELECT (5,10) < (5,12), (5,11) < (5,12), (5,12) < (5,12);
+-----------------+-----------------+-----------------+
| (5,10) < (5,12) | (5,11) < (5,12) | (5,12) < (5,12) |
+-----------------+-----------------+-----------------+
|               1 |               1 |               0 |
+-----------------+-----------------+-----------------+
1 row in set (0.07 sec)

关于RANGE COLUMNS的更多说明,可参考MySQL官方文档:

http://dev.mysql.com/doc/refman/5.6/en/partitioning-columns-range.html

LIST分区

LIST即列表分区。

格式如下:

CREATE TABLE employees (
    id INT NOT NULL,
    fname VARCHAR(30),
    lname VARCHAR(30),
    hired DATE NOT NULL DEFAULT '1970-01-01',
    separated DATE NOT NULL DEFAULT '9999-12-31',
    job_code INT,
    store_id INT
)
PARTITION BY LIST(store_id) (
    PARTITION pNorth VALUES IN (3,5,6,9,17),
    PARTITION pEast VALUES IN (1,2,10,11,19,20),
    PARTITION pWest VALUES IN (4,12,13,14,18),
    PARTITION pCentral VALUES IN (7,8,15,16)
);

LIST COLUMNS分区

LIST COLUMNS分区同样是LIST分区的一种特殊类型,它和RANGE COLUMNS分区较为相似,同样不接受表达式,同样支持多个列支持string,date和datetime类型。

格式如下:

CREATE TABLE customers_1 (
    first_name VARCHAR(25),
    last_name VARCHAR(25),
    street_1 VARCHAR(30),
    street_2 VARCHAR(30),
    city VARCHAR(15),
    renewal DATE
)
PARTITION BY LIST COLUMNS(renewal) (
    PARTITION pWeek_1 VALUES IN('2010-02-01', '2010-02-02', '2010-02-03',
        '2010-02-04', '2010-02-05', '2010-02-06', '2010-02-07'),
    PARTITION pWeek_2 VALUES IN('2010-02-08', '2010-02-09', '2010-02-10',
        '2010-02-11', '2010-02-12', '2010-02-13', '2010-02-14'),
    PARTITION pWeek_3 VALUES IN('2010-02-15', '2010-02-16', '2010-02-17',
        '2010-02-18', '2010-02-19', '2010-02-20', '2010-02-21'),
    PARTITION pWeek_4 VALUES IN('2010-02-22', '2010-02-23', '2010-02-24',
        '2010-02-25', '2010-02-26', '2010-02-27', '2010-02-28')
);

多列格式如下:

CREATE TABLE customers_2 (
    first_name VARCHAR(25),
    last_name VARCHAR(25),
    street_1 VARCHAR(30),
    street_2 VARCHAR(30),
    city VARCHAR(15),
    renewal DATE
)
PARTITION BY LIST COLUMNS(city,last_name,first_name) (
    PARTITION pRegion_1 VALUES IN (('Oskarshamn', 'Högsby', 'Mönsterås'),('Nässjö', 'Eksjö', 'Vetlanda')),
    PARTITION pRegion_2 VALUES IN(('Vimmerby', 'Hultsfred', 'Västervik'),('Uppvidinge', 'Alvesta', 'Växjo'))
);

HASH分区

和RANGE,LIST分区不同的是,HASH分区无需定义分区的条件。只需要指明分区数即可。

格式如下:

CREATE TABLE employees (
    id INT NOT NULL,
    fname VARCHAR(30),
    lname VARCHAR(30),
    hired DATE NOT NULL DEFAULT '1970-01-01',
    separated DATE NOT NULL DEFAULT '9999-12-31',
    job_code INT,
    store_id INT
)
PARTITION BY HASH(store_id)
PARTITIONS 4;

注意:

  1. HASH分区可以不用指定PARTITIONS子句,如上文中的PARTITIONS 4,则默认分区数为4。

  2. 不允许只写PARTITIONS,而不指定分区数。

  3. 同RANGE分区和LIST分区一样,PARTITION BY HASH (expr)子句中的expr返回的必须是整数值。

  4. HASH分区的底层实现其实是基于MOD函数。譬如,对于下表

CREATE TABLE t1 (col1 INT, col2 CHAR(5), col3 DATE)
    PARTITION BY HASH( YEAR(col3) )
    PARTITIONS 4;

如果你要插入一个col3为“2005-09-15”的记录,则分区的选择是根据以下值决定的:

MOD(YEAR('2005-09-01'),4)
=  MOD(2005,4)
=  1

LINEAR HASH分区

LINEAR HASH分区是HASH分区的一种特殊类型,与HASH分区是基于MOD函数不同的是,它基于的是另外一种算法。

格式如下:

CREATE TABLE employees (
    id INT NOT NULL,
    fname VARCHAR(30),
    lname VARCHAR(30),
    hired DATE NOT NULL DEFAULT '1970-01-01',
    separated DATE NOT NULL DEFAULT '9999-12-31',
    job_code INT,
    store_id INT
)
PARTITION BY LINEAR HASH( YEAR(hired) )
PARTITIONS 4;

说明:

  1. 它的优点是在数据量大的场景,譬如TB级,增加、删除、合并和拆分分区会更快,缺点是,相对于HASH分区,它数据分布不均匀的概率更大。

  2. 具体算法,可参考MySQL的官方文档

http://dev.mysql.com/doc/refman/5.6/en/partitioning-linear-hash.html

KEY分区

KEY分区其实跟HASH分区差不多,不同点如下:

  1. KEY分区允许多列,而HASH分区只允许一列。

  2. 如果在有主键或者唯一键的情况下,key中分区列可不指定,默认为主键或者唯一键,如果没有,则必须显性指定列。

  3. KEY分区对象必须为列,而不能是基于列的表达式。

  4. KEY分区和HASH分区的算法不一样,PARTITION BY HASH (expr),MOD取值的对象是expr返回的值,而PARTITION BY KEY (column_list),基于的是列的MD5值。

格式如下:

	CREATE TABLE k1 (
    id INT NOT NULL PRIMARY KEY,
    name VARCHAR(20)
)
PARTITION BY KEY()
PARTITIONS 2;

在没有主键或者唯一键的情况下,格式如下:

CREATE TABLE tm1 (
    s1 CHAR(32)
)
PARTITION BY KEY(s1)
PARTITIONS 10;

LINEAR KEY分区

同LINEAR HASH分区类似。

格式如下:

CREATE TABLE tk (
    col1 INT NOT NULL,
    col2 CHAR(5),
    col3 DATE
)
PARTITION BY LINEAR KEY (col1)
PARTITIONS 3;

总结:

1. MySQL分区中如果存在主键或唯一键,则分区列必须包含在其中。

2. 对于原生的RANGE分区,LIST分区,HASH分区,分区对象返回的只能是整数值。

3. RANGE COLUMNS,LIST COLUMNS,KEY,LINEAR KEY分区对象只能是列,不能是基于列的表达式。

分区的好处是:

  • 可以让单表存储更多的数据
  • 分区表的数据更容易维护,可以通过清楚整个分区批量删除大量数据,也可以增加新的分区来支持新插入的数据。另外,还可以对一个独立分区进行优化、检查、修复等操作
  • 部分查询能够从查询条件确定只落在少数分区上,速度会很快
  • 分区表的数据还可以分布在不同的物理设备上,从而搞笑利用多个硬件设备
  • 可以使用分区表赖避免某些特殊瓶颈,例如InnoDB单个索引的互斥访问、ext3文件系统的inode锁竞争
  • 可以备份和恢复单个分区

分区的限制和缺点:

  • 一个表最多只能有1024个分区
  • 如果分区字段中有主键或者唯一索引的列,那么所有主键列和唯一索引列都必须包含进来
  • 分区表无法使用外键约束 NULL值会使分区过滤无效
  • 所有分区必须使用相同的存储引擎

分区的类型:

  • RANGE分区:基于属于一个给定连续区间的列值,把多行分配给分区
  • LIST分区:类似于按RANGE分区,区别在于LIST分区是基于列值匹配一个离散值集合中的某个值来进行选择
  • HASH分区:基于用户定义的表达式的返回值来进行选择的分区,该表达式使用将要插入到表中的这些行的列值进行计算。这个函数可以包含MySQL中有效的、产生非负整数值的任何表达式
  • KEY分区:类似于按HASH分区,区别在于KEY分区只支持计算一列或多列,且MySQL服务器提供其自身的哈希函数。必须有一列或多列包含整数值具体关于mysql分区的概念请自行google或查询官方文档,我这里只是抛砖引玉了。
    我首先根据月份把上网记录表RANGE分区了12份,查询效率提高6倍左右,效果不明显,故:换id为HASH分区,分了64个分区,查询速度提升显著。问题解决! 结果如下:PARTITION BY HASH (id)PARTITIONS 64 select count() from readroom_website; --11901336行记录/ 受影响行数: 0 已找到记录: 1 警告: 0 持续时间 1 查询: 5.734 sec. / select * from readroom_website where month(accesstime) =11 limit 10;/ 受影响行数: 0 已找到记录: 10 警告: 0 持续时间 1 查询: 0.719 sec. */

4.分表

分表就是把一张大表,按照如上过程都优化了,还是查询卡死,那就把这个表分成多张表,把一次查询分成多次查询,然后把结果组合返回给用户。分表分为垂直拆分和水平拆分,通常以某个字段做拆分项。比如以id字段拆分为100张表: 表名为 tableName_id%100但:分表需要修改源程序代码,会给开发带来大量工作,极大的增加了开发成本,故:只适合在开发初期就考虑到了大量数据存在,做好了分表处理,不适合应用上线了再做修改,成本太高!!!而且选择这个方案,都不如选择我提供的第二第三个方案的成本低!故不建议采用。

5.分库

把一个数据库分成多个,建议做个读写分离就行了,真正的做分库也会带来大量的开发成本,得不偿失!不推荐使用。

转自:https://www.zhihu.com/question/19719997/answer/549041957

一、什么是索引?为什么要建立索引?

索引用于快速找出在某个列中有一特定值的行,不使用索引,MySQL必须从第一条记录开始读完整个表,直到找出相关的行,表越大,查询数据所花费的时间就越多,如果表中查询的列有一个索引,MySQL能够快速到达一个位置去搜索数据文件,而不必查看所有数据,那么将会节省很大一部分时间。

例如:有一张person表,其中有2W条记录,记录着2W个人的信息。有一个Phone的字段记录每个人的电话号码,现在想要查询出电话号码为xxxx的人的信息。

如果没有索引,那么将从表中第一条记录一条条往下遍历,直到找到该条信息为止。

如果有了索引,那么会将该Phone字段,通过一定的方法进行存储,好让查询该字段上的信息时,能够快速找到对应的数据,而不必在遍历2W条数据了。其中MySQL中的索引的存储类型有两种:BTREE、HASH。 也就是用树或者Hash值来存储该字段,要知道其中详细是如何查找的,就需要会算法的知识了。我们现在只需要知道索引的作用,功能是什么就行。

二、MySQL中索引的优点和缺点和使用原则

优点:

2、所有的MySql列类型(字段类型)都可以被索引,也就是可以给任意字段设置索引

3、大大加快数据的查询速度

缺点:

1、创建索引和维护索引要耗费时间,并且随着数据量的增加所耗费的时间也会增加

2、索引也需要占空间,我们知道数据表中的数据也会有最大上线设置的,如果我们有大量的索引,索引文件可能会比数据文件更快达到上线值

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

使用原则:

通过上面说的优点和缺点,我们应该可以知道,并不是每个字段度设置索引就好,也不是索引越多越好,而是需要自己合理的使用。

1、对经常更新的表就避免对其进行过多的索引,对经常用于查询的字段应该创建索引,

2、数据量小的表最好不要使用索引,因为由于数据较少,可能查询全部数据花费的时间比遍历索引的时间还要短,索引就可能不会产生优化效果。

3、在一同值少的列上(字段上)不要建立索引,比如在学生表的"性别"字段上只有男,女两个不同值。相反的,在一个字段上不同值较多可是建立索引。

上面说的只是很片面的一些东西,索引肯定还有很多别的优点或者缺点,还有使用原则,先基本上理解索引,然后等以后真正用到了,就会慢慢知道别的作用。注意,学习这张,很重要的一点就是必须先得知道索引是什么,索引是干嘛的,有什么作用,为什么要索引等等,如果不知道,就重复往上面看看写的文字,好好理解一下。一个表中很够创建多个索引,这些索引度会被存放到一个索引文件中(专门存放索引的地方)

三、索引的分类

注意:索引是在存储引擎中实现的,也就是说不同的存储引擎,会使用不同的索引

MyISAM和InnoDB存储引擎:只支持BTREE索引, 也就是说默认使用BTREE,不能够更换

MEMORY/HEAP存储引擎:支持HASH和BTREE索引

1、索引我们分为四类来讲 单列索引(普通索引,唯一索引,主键索引)、组合索引、全文索引、空间索引、

1.1、单列索引:一个索引只包含单个列,但一个表中可以有多个单列索引。 这里不要搞混淆了。

1.1.1、普通索引:

MySQL中基本索引类型,没有什么限制,允许在定义索引的列中插入重复值和空值,纯粹为了查询数据更快一点。

1.1.2、唯一索引:

索引列中的值必须是唯一的,但是允许为空值,

1.1.3、主键索引:

是一种特殊的唯一索引,不允许有空值。

1.2、组合索引

在表中的多个字段组合上创建的索引,只有在查询条件中使用了这些字段的左边字段时,索引才会被使用,使用组合索引时遵循最左前缀集合。这个如果还不明白,等后面举例讲解时在细说

1.3、全文索引

全文索引,只有在MyISAM引擎上才能使用,只能在CHAR,VARCHAR,TEXT类型字段上使用全文索引,介绍了要求,说说什么是全文索引,就是在一堆文字中,通过其中的某个关键字等,就能找到该字段所属的记录行,比如有"你是个大煞笔,二货 …" 通过大煞笔,可能就可以找到该条记录。这里说的是可能,因为全文索引的使用涉及了很多细节,我们只需要知道这个大概意思,如果感兴趣进一步深入使用它,那么看下面测试该索引时,会给出一个博文,供大家参考。

1.4、空间索引

空间索引是对空间数据类型的字段建立的索引,MySQL中的空间数据类型有四种,GEOMETRY、POINT、LINESTRING、POLYGON。

在创建空间索引时,使用SPATIAL关键字。

要求,引擎为MyISAM,创建空间索引的列,必须将其声明为NOT NULL。具体细节看下面

四、索引操作(创建和删除)

4.1、创建索引

4.1.1、创建表的时候创建索引

格式:CREATE TABLE 表名[字段名 数据类型] [UNIQUE|FULLTEXT|SPATIAL|…] [INDEX|KEY] [索引名字] (字段名[length])   [ASC|DESC]

|--------------------------------------| |-----------------------------------| |------------| |---------| |---------------|   |------------|

普通创建表语句        设置什么样的索引(唯一、全文等)  索引关键字  索引名字 对哪个字段设置索引  对索引进行排序

4.1.1.1、创建普通索引

CREATE TABLE book                    CREATE TABLE book

(                              (

bookid INT NOT NULL,                  bookid INT NOT NULL,

bookname VARCHAR(255) NOT NULL,           bookname VARCHAR(255) NOT NULL,

authors VARCHAR(255) NOT NULL,            authors VARCHAR(255) NOT NULL,

info VARCHAR(255) NULL,                info VARCHAR(255) NULL,

comment VARCHAR(255) NULL,             comment VARCHAR(255) NULL,

year_publication YEAR NOT NULL,            year_publication YEAR NOT NULL,

INDEX(year_publication)                 KEY(year_publication)

);                              );

上面两种方式创建度可以,通过这个例子可以对比一下格式,就差不多明白格式是什么意思了。

通过打印结果,我们在创建索引时没写索引名的话,会自动帮我们用字段名当作索引名。

测试:看是否使用了索引进行查询。

EXPLAIN SELECT * FROM book WHERE year_publication = 1990\G;

解释:虽然表中没数据,但是有EXPLAIN关键字,用来查看索引是否正在被使用,并且输出其使用的索引的信息。

id: SELECT识别符。这是SELECT的查询序列号,也就是一条语句中,该select是第几次出现。在次语句中,select就只有一个,所以是1.

select_type:所使用的SELECT查询类型,SIMPLE表示为简单的SELECT,不实用UNION或子查询,就为简单的SELECT。也就是说在该SELECT查询时会使用索引。其他取值,PRIMARY:最外面的SELECT.在拥有子查询时,就会出现两个以上的SELECT。UNION:union(两张表连接)中的第二个或后面的select语句 SUBQUERY:在子查询中,第二SELECT。

table:数据表的名字。他们按被读取的先后顺序排列,这里因为只查询一张表,所以只显示book

type:指定本数据表和其他数据表之间的关联关系,该表中所有符合检索值的记录都会被取出来和从上一个表中取出来的记录作联合。ref用于连接程序使用键的最左前缀或者是该键不是 primary key 或 unique索引(换句话说,就是连接程序无法根据键值只取得一条记录)的情况。当根据键值只查询到少数几条匹配的记录时,这就是一个不错的连接类型。(注意,个人这里不是很理解,百度了很多资料,全是大白话,等以后用到了这类信息时,在回过头来补充,这里不懂对后面的影响不大。)可能的取值有 system、const、eq_ref、index和All

possible_keys:MySQL在搜索数据记录时可以选用的各个索引,该表中就只有一个索引,year_publication

key:实际选用的索引

key_len:显示了mysql使用索引的长度(也就是使用的索引个数),当 key 字段的值为 null时,索引的长度就是 null。注意,key_len的值可以告诉你在联合索引中mysql会真正使用了哪些索引。这里就使用了1个索引,所以为1,

ref:给出关联关系中另一个数据表中数据列的名字。常量(const),这里使用的是1990,就是常量。

rows:MySQL在执行这个查询时预计会从这个数据表里读出的数据行的个数。

extra:提供了与关联操作有关的信息,没有则什么都不写。

上面的一大堆东西能看懂多少看多少,我们最主要的是看possible_keys和key 这两个属性,上面显示了key为year_publication。说明使用了索引。

4.1.1.2、创建唯一索引

CREATE TABLE t1

(

id INT NOT NULL,

name CHAR(30) NOT NULL,

UNIQUE INDEX UniqIdx(id)

);

解释:对id字段使用了索引,并且索引名字为UniqIdx。

SHOW CREATE TABLE t1\G;

要查看其中查询时使用的索引,必须先往表中插入数据,然后在查询数据,不然查找一个没有的id值,是不会使用索引的。

INSERT INTO t1 VALUES(1,‘xxx’);

EXPLAIN SELECT * FROM t1 WHERE id = 1\G;

可以看到,通过id查询时,会使用唯一索引。并且还实验了查询一个没有的id值,则不会使用索引,我觉得原因是所有的id应该会存储到一个const tables中,到其中并没有该id值,那么就没有查找的必要了。

4.1.1.3、创建主键索引

CREATE TABLE t2

(

id INT NOT NULL,

name CHAR(10),

PRIMARY KEY(id)

);

INSERT INTO t2 VALUES(1,‘QQQ’);

EXPLAIN SELECT * FROM t2 WHERE id = 1\G;

通过这个主键索引,我们就应该反应过来,其实我们以前声明的主键约束,就是一个主键索引,只是之前我们没学过,不知道而已。

4.1.1.4、创建单列索引

这个其实就不用在说了,前面几个就是单列索引。

4.1.1.5、创建组合索引

组合索引就是在多个字段上创建一个索引

创建一个表t3,在表中的id、name和age字段上建立组合索引

CREATE TABLE t3

(

id INT NOT NULL,

name CHAR(30) NOT NULL,

age INT NOT NULL,

info VARCHAR(255),

INDEX MultiIdx(id,name,age)

);

SHOW CREATE t3\G;

解释最左前缀

组合索引就是遵从了最左前缀,利用索引中最左边的列集来匹配行,这样的列集称为最左前缀,不明白没关系,举几个例子就明白了,例如,这里由id、name和age3个字段构成的索引,索引行中就按id/name/age的顺序存放,索引可以索引下面字段组合(id,name,age)、(id,name)或者(id)。如果要查询的字段不构成索引最左面的前缀,那么就不会是用索引,比如,age或者(name,age)组合就不会使用索引查询

在t3表中,查询id和name字段

EXPLAIN SELECT * FROM t3 WHERE id = 1 AND name = ‘joe’\G;

在t3表中,查询(age,name)字段,这样就不会使用索引查询。来看看结果

EXPLAIN SELECT * FROM t3 WHERE age = 3 AND name = ‘bob’\G;

4.1.1.6、创建全文索引

全文索引可以用于全文搜索,但只有MyISAM存储引擎支持FULLTEXT索引,并且只为CHAR、VARCHAR和TEXT列服务。索引总是对整个列进行,不支持前缀索引,

CREATE TABLE t4

(

id INT NOT NULL,

name CHAR(30) NOT NULL,

age INT NOT NULL,

info VARCHAR(255),

FULLTEXT INDEX FullTxtIdx(info)

)ENGINE=MyISAM;

SHOW CREATE TABLE t4\G;

使用一下什么叫做全文搜索。就是在很多文字中,通过关键字就能够找到该记录。

INSERT INTO t4 VALUES(8,‘AAA’,3,‘text is so good,hei,my name is bob’),(9,‘BBB’,4,‘my name is gorlr’);

SELECT * FROM t4 WHERE MATCH(info) AGAINST(‘gorlr’);

EXPLAIN SELECT * FROM t4 WHERE MATCH(info) AGAINST(‘gorlr’);

注意:在使用全文搜索时,需要借助MATCH函数,并且其全文搜索的限制比较多,比如只能通过MyISAM引擎,比如只能在CHAR,VARCHAR,TEXT上设置全文索引。比如搜索的关键字默认至少要4个字符,比如搜索的关键字太短就会被忽略掉。等等,如果你们在实验的时候可能会实验不出来。感兴趣的同学可以看看这篇文章,全文搜索的使用

4.1.1.7、创建空间索引

空间索引也必须使用MyISAM引擎, 并且空间类型的字段必须为非空。 这个空间索引具体能干嘛我也不知道,可能跟游戏开发有关,可能跟别的东西有关,等遇到了自然就知道了,现在只要求能够创建出来。

CREATE TABLE t5

(

g GEOMETRY NOT NULL,

SPATIAL INDEX spatIdx(g)

) ENGINE = MyISAM;

SHOW CREATE TABLE t5\G;

4.1.2、在已经存在的表上创建索引

格式:ALTER TABLE 表名 ADD[UNIQUE|FULLTEXT|SPATIAL] [INDEX|KEY] [索引名] (索引字段名)[ASC|DESC]

有了上面的基础,这里就不用过多陈述了。

命令一:SHOW INDEX FROM 表名\G

查看一张表中所创建的索引

SHOW INDEX FROM book\G;

挑重点讲,我们需要了解的就5个,用红颜色标记了的,如果想深入了解,可以去查查该方面的资料,我个人觉得,这些等以后实际工作中遇到了在做详细的了解把。

Table:创建索引的表

Non_unique:表示索引非唯一,1代表 非唯一索引, 0代表 唯一索引,意思就是该索引是不是唯一索引

Key_name:索引名称

Seq_in_index 表示该字段在索引中的位置,单列索引的话该值为1,组合索引为每个字段在索引定义中的顺序(这个只需要知道单列索引该值就为1,组合索引为别的)

Column_name:表示定义索引的列字段

Sub_part:表示索引的长度

Null:表示该字段是否能为空值

Index_type:表示索引类型

4.1.2.1、为表添加索引

就拿上面的book表来说。本来已经有了一个year_publication,现在我们为该表在加一个普通索引

ALTER TABLE book ADD INDEX BkNameIdx(bookname(30));

看输出结果,就能知道,添加索引成功了。

这里只是拿普通索引做个例子,添加其他索引也是一样的。依葫芦画瓢而已。这里就不一一做讲解了。

4.1.2.2、使用CREATE INDEX创建索引。

格式:CREATE [UNIQUE|FULLTEXT|SPATIAL] [INDEX|KEY] 索引名称 ON 表名(创建索引的字段名[length])[ASC|DESC]

解释:其实就是换汤不换药,格式改变了一下而已,做的事情跟上面完全一样,做一个例子。

在为book表增加一个普通索引,字段为authors。

CREATE INDEX BkBookNameIdx ON book(bookname);

SHOW INDEX FROM book\G;  //查看book表中的索引

解释:第一条截图没截到,因为图太大了,这里只要看到有我们新加进去的索引就证明成功了。。其他索引也是一样的创建。

4.2、删除索引

前面讲了对一张表中索引的添加,查询的方法。

添加的两种方式

1在创建表的同时如何创建索引,

2在创建了表之后如何给表添加索引的两种方式,

查询的方式

SHOW INDEX FROM 表名\G;  \G只是让输出的格式更好看

现在来说说如何给表删除索引的两种操作。

格式一:ALTER TABLE 表名 DROP INDEX 索引名。

很简单的语句,现在通过一个例子来看看,还是对book表进行操作,删除我们刚才为其添加的索引。

1、删除book表中的名称为BkBookNameIdx的索引。

ALTER TABLE book DROP INDEX BkBookNameIdx;

SHOW INDEX FROM book\G;  //在查看book表中的索引,就会发现BkBookNameIdx这个索引已经不在了

格式二:DROP INDEX 索引名 ON 表名;

删除book表中名为BkNameIdx的索引

DROP INDEX BkNameIdx ON book;

SHOW INDEX FROM book\G;

转自:https://www.cnblogs.com/whgk/p/6179612.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值