MySQL

简单来说 MySQL 主要分为 Server 层和存储引擎层:

  • Server 层:主要包括连接器、查询缓存、分析器、优化器、执行器等,所有跨存储引擎的功能都在这一层实现,比如存储过程、触发器、视图,函数等,还有一个通用的日志模块 binglog 日志模块。
  • 存储引擎: 主要负责数据的存储和读取,采用可以替换的插件式架构,支持 InnoDB、MyISAM、Memory 等多个存储引擎,其中 InnoDB 引擎有自有的日志模块 redolog 模块。现在最常用的存储引擎是 InnoDB,它从 MySQL 5.5.5 版本开始就被当做默认存储引擎了。(5.5版之前MyISAM是MySQL的默认数据库引擎)

两者的对比:

  • 是否支持行级锁 : MyISAM 只有表级锁(table-level locking),而InnoDB 支持行级锁(row-level locking)和表级锁,默认为行级锁。
  • 是否支持事务和崩溃后的安全恢复: MyISAM 强调的是性能,每次查询具有原子性,其执行速度比InnoDB类型更快,但是不提供事务支持。但是InnoDB 提供事务支持,外部键等高级数据库功能。 具有事务(commit)、回滚(rollback)和崩溃修复能力(crash recovery capabilities)的事务安全(transaction-safe (ACID compliant))型表。
  • 是否支持外键: MyISAM不支持,而InnoDB支持。
  • 是否支持MVCC :仅 InnoDB 支持。
    应对高并发事务, MVCC比单纯的加锁更高效;MVCC只在 READ COMMITTED 和 REPEATABLE READ 两个隔离级别下工作;MVCC可以使用 乐观(optimistic)锁 和 悲观(pessimistic)锁来实现;各数据库中MVCC实现并不统一。

表级锁和行级锁对比:

  • 表级锁: MySQL中锁定 粒度最大 的一种锁,对当前操作的整张表加锁,实现简单,资源消耗也比较少,加锁快,不会出现死锁。其锁定粒度最大,触发锁冲突的概率最高,并发度最低,MyISAM和 InnoDB引擎都支持表级锁。
  • 行级锁: MySQL中锁定 粒度最小 的一种锁,只针对当前操作的行进行加锁。 行级锁能大大减少数据库操作的冲突。其加锁粒度最小,并发度高,但加锁的开销也最大,加锁慢,会出现死锁。

为什么myisam查询比innodb快?

  • 查询的时候,由于innodb支持事务,所以会有MVCC的一个比较。这个过程会损耗性能。
  • 查询的时候,如果走了索引,由于innodb是聚簇索引,会有一个回表的过程,即:先去非聚簇索引树中查询数据,找到数据对应的key之后,再通过key回表到聚簇索引树,最后找到需要的数据。
    myisam直接就是簇集索引,查询的时候查到的最后结果不是聚簇索引树的key,而是磁盘地址,所以会直接去查询磁盘。
  • 锁的一个损耗,innodb锁支持行锁,在检查锁的时候不仅检查表锁,还要看行锁。

sql调优

  • 创建索引,考虑在经常需要进行检索的字段上创建索引,在where及order by涉及的列上建立索引,避免在索引上使用计算
  • 调整Where字句中的连接顺序,排除越多的条件放在第一个
  • 动态sql使用预编译查询
  • SQL语句中连接多个表时,使用表的别名,减少那些由列名歧义引起的语法错误
  • 查询select尽量不使用*号查询,用具体的字段代替
  • 避免在where字句中对字段进行null值判断,否则引擎放弃使用索引而进行全表查询

索引

为什么要使用索引?

  • 通过创建唯一性索引,可以保证数据库表中每一行数据的唯一性。
  • 可以大大加快 数据的检索速度(大大减少的检索的数据量), 这也是创建索引的最主要的原因。
  • 帮助服务器避免排序和临时表。
  • 将随机IO变为顺序IO
  • 可以加速表和表之间的连接,特别是在实现数据的参考完整性方面特别有意义。

MySQL索引使用的数据结构主要有BTree索引 和 哈希索引 。对于哈希索引来说,底层的数据结构就是哈希表,因此在绝大多数需求为单条记录查询的时候,可以选择哈希索引,查询性能最快;其余大部分场景,建议选择BTree索引。

  • Hash 索引不支持顺序(Order BY排序)和范围查询是它最大的缺点。
    例:SELECT * FROM tb1 WHERE id < 500;
    B+树是有序的,在这种范围查询中,优势非常大,直接遍历比 500 小的叶子节点就够了。而 Hash 索引是根据 hash 算法来定位的,把 1 - 499 的数据每个都进行一次 hash 计算来定位。
  • Hash索引无法进行模糊查询。
    而B+ 树使用 LIKE 进行模糊查询的时候,LIKE后面前模糊查询(比如%开头)的话可以起到优化的作用。
  • Hash索引不支持联合索引的最左侧原则(即联合索引的部分索引无法使用),而B+树可以。
    对于联合索引来说,Hash索引在计算Hash值的时候是将索引键合并后再一起计算Hash值,所以不会针对每个索引单独计算Hash值。因此如果用到联合索引的一个或多个索引时,联合索引无法被利用。

MySQL的BTree索引使用的是B树中的B+Tree,但对于主要的两种存储引擎的实现方式是不同的。

  • MyISAM: B+Tree叶节点的data域存放的是数据记录的地址。在索引检索的时候,首先按照B+Tree搜索算法搜索索引,如果指定的Key存在,则取出其 data 域的值,然后以 data 域的值为地址读取相应的数据记录。这被称为“非聚簇索引”。
  • InnoDB: 其数据文件本身就是索引文件。相比MyISAM,索引文件和数据文件是分离的,其表数据文件本身就是按B+Tree组织的 一个索引结构,树的叶节点data域保存了完整的数据记录。这个索引的key是数据表的主键,因此InnoDB表数据文件本身就是主索引。这被称为“聚簇索引(或聚集索引)”。而其余的索引都作为辅助索引,辅助索引的data域存储相应记录主键的值而不是地址,这也是和MyISAM不同的地方。

选择索引和编写利用这些索引的查询的3个原则

  • 单行访问是很慢的。如果服务器从存储中读取一个数据块只是为了获取其中一行,那么就浪费了很多工作。最好读取的块中能包含尽可能多所需要的行。使用索引可以创建位置引,用以提升效率。
  • 按顺序访问范围数据是很快的,这有两个原因。第一,顺序 I/O 不需要多次磁盘寻道,所以比随机I/O要快很多。第二,如果服务器能够按需要顺序读取数据,那么就不再需要额外的排序操作,并且GROUPBY查询也无须再做排序和将行按组进行聚合计算了。
  • 索引覆盖查询是很快的。如果一个索引包含了查询需要的所有列,那么存储引擎就 不需要再回表查找行。这避免了大量的单行访问。

最左前缀原则

  • MySQL中的索引可以以一定顺序引用多列,这种索引叫作联合索引。如User表的name和city加联合索引就是(name,city),而最左前缀原则指的是,如果查询的时候查询条件精确匹配索引的左边连续一列或几列,则此列就可以被用到。如下:
select * from user where name=xx and city=xx ; //可以命中索引
select * from user where name=xx ; // 可以命中索引
select * from user where city=xx ; // 无法命中索引   
  • 补充:查询的时候如果两个条件都用上了,但是顺序不同,如 city= xx and name =xx,那么现在的查询引擎会自动优化为匹配联合索引的顺序,这样是能够命中索引的。
  • 由于最左前缀原则,在创建联合索引时,索引字段的顺序需要考虑字段值去重之后的个数,较多的放前面。

覆盖索引

  • 如果一个索引包含(或者说覆盖)所有需要查询的字段的值,我们就称之为“覆盖索引”。我们知道在 InnoDB 存储引擎中,如果不是主键索引,叶子节点存储的是主键+列值。最终还是要“回表”,也就是要通过主键再查找一次。这样就会比较慢覆盖索引就是把要查询出的列和索引是对应的,不做回表操作!
  • 覆盖索引即需要查询的字段正好是索引的字段,那么直接根据该索引,就可以查到数据了, 而无需回表查询。

索引失效

  • like以%开头,索引无效
  • or语句前后没有同时使用索引
  • 组合索引,不是使用第一索引,索引失效(最左前缀原则)
  • 在索引列上使用IS NULL或IS NOT NULL操作
  • 在索引字段上使用not,<>,!=是用不到索引的
  • 对索引字段进行计算操作、使用函数
  • 数据类型出现隐式转化。如varchar不加单引号的话可能自动转换为int型,使索引无效

如何看sql有无用索引

  • 使用解释函数explain,只需在sql语句之前添加explain即可

数据库查找去重

  • distinct 去除重复记录

Mysql如何为表字段添加索引???

  • 添加PRIMARY KEY(主键索引)
    ALTER TABLE table_name ADD PRIMARY KEY ( column )

  • 添加UNIQUE(唯一索引)
    ALTER TABLE table_name ADD UNIQUE ( column )

  • 添加INDEX(普通索引)
    ALTER TABLE table_name ADD INDEX index_name ( column )

  • 添加FULLTEXT(全文索引)
    ALTER TABLE table_name ADD FULLTEXT ( column)

  • 添加多列索引
    ALTER TABLE table_name ADD INDEX index_name ( column1, column2, column3 )

事务

事务是逻辑上的一组操作,要么都执行,要么都不执行。
四大特性:

  • 原子性(Atomicity): 事务是最小的执行单位,不允许分割。事务的原子性确保动作要么全部完成,要么完全不起作用;
  • 一致性(Consistency): 执行事务后,数据库从一个正确的状态变化到另一个正确的状态;
  • 隔离性(Isolation): 并发访问数据库时,一个用户的事务不被其他事务所干扰,各并发事务之间数据库是独立的;
  • 持久性(Durability): 一个事务被提交之后。它对数据库中数据的改变是持久的,即使数据库发生故障也不应该对其有任何影响。

并发事务可能带来哪些问题?

  • 脏读(Dirty read): 当一个事务正在访问数据并且对数据进行了修改,而这种修改还没有提交到数据库中,这时另外一个事务也访问了这个数据,然后使用了这个数据。因为这个数据是还没有提交的数据,那么另外一个事务读到的这个数据是“脏数据”,依据“脏数据”所做的操作可能是不正确的。
  • 丢失修改(Lost to modify): 指在一个事务读取一个数据时,另外一个事务也访问了该数据,那么在第一个事务中修改了这个数据后,第二个事务也修改了这个数据。这样第一个事务内的修改结果就被丢失,因此称为丢失修改。。
  • 不可重复读(Unrepeatableread): 指在一个事务内多次读同一数据。在这个事务还没有结束时,另一个事务也访问该数据。那么,在第一个事务中的两次读数据之间,由于第二个事务的修改导致第一个事务两次读取的数据可能不太一样。这就发生了在一个事务内两次读到的数据是不一样的情况,因此称为不可重复读。
  • 幻读(Phantom read): 幻读与不可重复读类似。它发生在一个事务(T1)读取了几行数据,接着另一个并发事务(T2)插入了一些数据时。在随后的查询中,第一个事务(T1)就会发现多了一些原本不存在的记录,就好像发生了幻觉一样,所以称为幻读。
  • 不可重复读的重点是修改比如多次读取一条记录发现其中某些列的值被修改,幻读的重点在于新增或者删除比如多次读取一条记录发现记录增多或减少了。

SQL 标准定义了四个事务隔离级别:

  • READ-UNCOMMITTED(读取未提交): 最低的隔离级别,允许读取尚未提交的数据变更,可能会导致脏读、幻读或不可重复读。
  • READ-COMMITTED(读取已提交): 允许读取并发事务已经提交的数据,可以阻止脏读,但是幻读或不可重复读仍有可能发生。
  • REPEATABLE-READ(可重复读): 对同一字段的多次读取结果都是一致的,除非数据是被本身事务自己所修改,可以阻止脏读和不可重复读,但幻读仍有可能发生。(MySQL的默认隔离级别
  • SERIALIZABLE(可串行化): 最高的隔离级别,完全服从ACID的隔离级别。所有的事务依次逐个执行,这样事务之间就完全不可能产生干扰,也就是说,该级别可以防止脏读、不可重复读以及幻读。

大表优化

当MySQL单表记录数过大时,数据库的CRUD性能会明显下降,一些常见的优化措施如下:

  1. 限定数据的范围
    务必禁止不带任何限制数据范围条件的查询语句。比如:我们当用户在查询订单历史的时候,我们可以控制在一个月的范围内;

  2. 读/写分离
    经典的数据库拆分方案,主库负责写,从库负责读;

  3. 垂直分区
    根据数据库里面数据表的相关性进行拆分。例如,用户表中既有用户的登录信息又有用户的基本信息,可以将用户表拆分成两个单独的表,甚至放到单独的库做分库。
    优点: 可以使得列数据变小,在查询时减少读取的Block数,减少I/O次数。此外,垂直分区可以简化表的结构,易于维护。
    缺点: 主键会出现冗余,需要管理冗余列,并会引起Join操作,可以通过在应用层进行Join来解决。此外,垂直分区会让事务变得更加复杂;

  4. 水平分区
    保持数据表结构不变,通过某种策略存储数据分片。这样每一片数据分散到不同的表或者库中,达到了分布式的目的。 水平拆分可以支撑非常大的数据量。例如:我们可以将用户信息表拆分成多个用户信息表,这样就可以避免单一表数据量过大对性能造成影响。
    分表仅仅是解决了单一表数据过大的问题,但由于表的数据还是在同一台机器上,其实对于提升MySQL并发能力没有什么意义,所以,水平拆分最好分库 。

分库分表之后,id 主键如何处理?

  • 因为要是分成多个表之后,每个表都是从 1 开始累加,这样是不对的,我们需要一个全局唯一的 id 来支持。
  • 生成全局 id 有下面这几种方式:
    UUID:不适合作为主键,因为太长了,并且无序不可读,查询效率低。比较适合用于生成唯一的名字的标示比如文件的名字。
    数据库自增 id : 两台数据库分别设置不同步长,生成不重复ID的策略来实现高可用。这种方式生成的 id 有序,但是需要独立部署数据库实例,成本高,还会有性能瓶颈。
    利用 redis 生成 id : 性能比较好,灵活方便,不依赖于数据库。但是,引入了新的组件造成系统更加复杂,可用性降低,编码更加复杂,增加了系统成本。
    Twitter的snowflake算法 。
    美团的Leaf分布式ID生成系统。

一个 SQL 执行的很慢,我们要分两种情况讨论:

1、大多数情况下很正常,偶尔很慢,则有如下原因

(1)、数据库在刷新脏页,例如 redo log 写满了需要同步到磁盘。

(2)、执行的时候,遇到锁,如表锁、行锁。

2、这条 SQL 语句一直执行的很慢,则有如下原因。

(1)、没有用上索引:例如该字段没有索引;由于对字段进行运算、函数操作导致无法用索引。

(2)、数据库选错了索引。

query接口的list方法和iterate方法有什么区别(n+1)

  • 对于list方法而言,实际上是通过一条Select SQL获取所有的记录。并将其读出,填入到POJO中返回。
  • 而iterate 方法,则是首先通过一条Select SQL 获取所有符合查询条件的记录的id,再对这个id 集合进行循环操作,通过单独的Select SQL 取出每个id 所对应的记录(n+1),之后填入POJO中返回。

==================================================================================

建表规范

    - 每个表保存一个实体信息
    - 每个具有一个ID字段作为主键
    - ID主键 + 原子表
  • 第一范式
    字段不能再分,就满足第一范式。
  • 第二范式
    满足第一范式的前提下,不能出现部分依赖。
    消除复合主键就可以避免部分依赖。增加单列关键字。
  • 第三范式
    满足第二范式的前提下,不能出现传递依赖。
    某个字段依赖于主键,而有其他字段依赖于该字段。这就是传递依赖。
    将一个实体信息的数据放在一个表内实现。

列属性(列约束)

  1. PRIMARY 主键
    • 能唯一标识记录的字段,可以作为主键。主键具有唯一性。主键字段的值不能为null。声明字段时,用 primary key 标识。

      也可以在字段列表之后声明
      例:create table tab ( id int, stu varchar(10), primary key (id));

    • 主键可以由多个字段共同组成。此时需要在字段列表后声明的方法。
      例:create table tab ( id int, stu varchar(10), age int, primary key (stu, age));

  2. UNIQUE 唯一索引(唯一约束)
    使得某字段的值也不能重复。
  3. NULL 约束
    • null不是数据类型,是列的一个属性。表示当前列是否可以为null,表示什么都没有。
      null, 允许为空。默认。
      not null, 不允许为空。
      insert into tab values (null, ‘val’);
      – 此时表示将第一个字段的值设为null, 取决于该字段是否允许为null
  4. DEFAULT 默认值属性
    当前字段的默认值。
    insert into tab values (default, ‘val’); – 此时表示强制使用默认值。
    create table tab ( add_time timestamp default current_timestamp );
    – 表示将当前时间的时间戳设为默认值。
    current_date, current_time
  5. AUTO_INCREMENT 自动增长约束
    自动增长必须为索引(主键或unique)
    只能存在一个字段为自动增长。
    默认为1开始自动增长。可以通过表属性 auto_increment = x进行设置,或 alter table tbl auto_increment = x;
  6. COMMENT 注释
    例:create table tab ( id int ) comment ‘注释内容’;
  7. FOREIGN KEY 外键约束
    用于限制主表与从表数据完整性。
    alter table t1 add constraint t1_t2_fk foreign key (t1_id) references t2(id);
    – 将表t1的t1_id外键关联到表t2的id字段。
    – 每个外键都有一个名字,可以通过 constraint 指定
    存在外键的表,称之为从表(子表),外键指向的表,称之为主表(父表)。
    作用:保持数据一致性,完整性,主要目的是控制存储在外键表(从表)中的数据。

SELECT

  • select_expr
    – 可以用 * 表示所有字段。
    select * from tb;
    – 可以使用表达式(计算公式、函数调用、字段也是个表达式)
    select stu, 29+25, now() from tb;
    – 可以为每个列使用别名。适用于简化列标识,避免多个列标识符重复。
    - 使用 as 关键字,也可省略 as.
    select stu+10 as add10 from tb;
  • FROM 子句
    – 可以为表起别名。使用as关键字。
    SELECT * FROM tb1 AS tt, tb2 AS bb;
    – from子句后,可以同时出现多个表。
    – 多个表会横向叠加到一起,而数据会形成一个笛卡尔积。
    SELECT * FROM tb1, tb2;
    – 向优化符提示如何选择索引
    USE INDEX、IGNORE INDEX、FORCE INDEX
    SELECT * FROM table1 USE INDEX (key1,key2) WHERE key1=1 AND key2=2 AND key3=3;
    SELECT * FROM table1 IGNORE INDEX (key3) WHERE key1=1 AND key2=2 AND key3=3;
  • WHERE 子句
    – 从from获得的数据源中进行筛选。
    – 整型1表示真,0表示假。
    – 表达式由运算符和运算数组成。
    – 运算数:变量(字段)、值、函数返回值
  • GROUP BY 子句, 分组子句
    GROUP BY 字段/别名 [排序方式]
    分组后会进行排序。升序:ASC,降序:DESC
    以下[合计函数]需配合 GROUP BY 使用:
    count 返回不同的非NULL值数目 count(*)、count(字段)
    sum 求和
    max 求最大值
    min 求最小值
    avg 求平均值
    group_concat 返回带有来自一个组的连接的非NULL值的字符串结果。组内字符串连接。
  • HAVING 子句,条件子句
    与 where 功能、用法相同,执行时机不同。
    where 在开始时执行检测数据,对原数据进行过滤。
    having 对筛选出的结果再次进行过滤。
    having 字段必须是查询出来的,where 字段必须是数据表存在的。
    where 不可以使用字段的别名,having 可以。因为执行WHERE代码时,可能尚未确定列值。
    where 不可以使用合计函数。一般需用合计函数才会用 having
    !!SQL标准要求HAVING必须引用GROUP BY子句中的列或用于合计函数中的列。
  • ORDER BY 子句,排序子句
    order by 排序字段/别名 排序方式 [,排序字段/别名 排序方式]…
    升序:ASC,降序:DESC
    支持多个字段的排序。
  • LIMIT 子句,限制结果数量子句
    仅对处理好的结果进行数量限制。将处理好的结果的看作是一个集合,按照记录出现的顺序,索引从0开始。
    limit 起始位置, 获取条数
    省略第一个参数,表示从索引0开始。limit 获取条数
  • DISTINCT, ALL 选项
    distinct 去除重复记录
    默认为 all, 全部记录

UNION

  • 将多个select查询的结果组合成一个结果集合。
    SELECT … UNION [ALL|DISTINCT] SELECT …
    默认 DISTINCT 方式,即所有返回的行都是唯一的
  • 建议,对每个SELECT查询加上小括号包裹。
  • 每个select查询的字段列表(数量、类型)应一致,因为结果中的字段名以第一条select语句为准。

子查询

  • 子查询需用括号包裹。
  • from型
    from后要求是一个表,必须给子查询结果取个别名。
    子查询返回一个表,表型子查询。
    select * from (select * from tb where id>0) as subfrom where id>1;
  • where型
    子查询返回一个值,标量子查询。
    不需要给子查询取别名。
    where子查询内的表,不能直接用以更新。
    select * from tb where money = (select max(money) from tb);
  • 列子查询
    如果子查询结果返回的是一列。
    使用 in 或 not in 完成查询
    exists 和 not exists 条件
    如果子查询返回数据,则返回1或0。常用于判断条件。
    select column1 from t1 where exists (select * from t2);
  • 行子查询
    查询条件是一个行。
    select * from t1 where (id, gender) in (select id, gender from t2);
    行构造符:(col1, col2, …) 或 ROW(col1, col2, …)
    行构造符通常用于与对能返回两个或两个以上列的子查询进行比较。
  • 特殊运算符
    != all() 相当于 not in
    = some() 相当于 in。any 是 some 的别名
    != some() 不等同于 not in,不等于其中某一个。
    all, some 可以配合其他运算符一起使用。

连接查询(join)

  • 将多个表的字段进行连接,可以指定连接条件。
  • 内连接(inner join)
    默认就是内连接,可省略inner。
    只有数据存在时才能发送连接。即连接结果不能出现空行。
    on 表示连接条件。其条件表达式与where类似。也可以省略条件(表示条件永远为真)
    也可用where表示连接条件。
    还有 using, 但需字段名相同。 using(字段名)
  • 交叉连接 cross join
    即,没有条件的内连接。
    select * from tb1 cross join tb2;
  • 外连接(outer join)
    如果数据不存在,也会出现在连接结果中。
    – 左外连接 left join
    如果数据不存在,左表记录会出现,而右表为null填充
    – 右外连接 right join
    如果数据不存在,右表记录会出现,而左表为null填充
  • 自然连接(natural join)
    自动判断连接条件完成连接。
    相当于省略了using,会自动查找相同字段名。
    natural join
    natural left join
    natural right join

TRUNCATE

  • 清空数据删除重建表
  • 和delete区别:
    1,truncate 是删除表再创建,delete 是逐条删除
    2,truncate 重置auto_increment的值。而delete不会
    3,truncate 不知道删除了几条,而delete知道。
    4,当被用于带分区的表时,truncate 会保留分区
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值