常见问题

数据类型

MySQL数据类型-菜鸟教程 

MYSQL中数据类型介绍

整数: int(m)里的m是表示数据显示宽度,浮点数,定点数。

字符串:char(n)4.0 n 代表字节,5.0 n 代表字符 (UTF-8=3zj,GBK=2zj)

 char 固定的字符数,空格补上;检索速度快。

 varchar 字符数+1个字节(n<=255)或2个字节(n>255)

 text 字符数+2个字节;不能有默认值;索引要指定前多少个字符;文本方式存储

 blob 二进制方式存储

innodb的读写参数优化

(1)、读取参数
global buffer pool以及 local buffer;

(2)、写入参数;
innodb_flush_log_at_trx_commit
innodb_buffer_pool_size

(3)、与IO相关的参数;
innodb_write_io_threads = 8
innodb_read_io_threads = 8
innodb_thread_concurrency = 0

(4)、缓存参数以及缓存的适用场景。
query cache/query_cache_type

MySQL索引详解 (一般使用磁盘I/O次数评价索引结构的优劣。)

 磁盘存取原理

 局部性原理与磁盘预读

M 阶 B-Tree

 图片 1

 根节点至少有2个子树。

 每个非叶子节点由n-1个key和n个指针组成。

 分支节点至少拥有m/2颗子树,最多拥有m个子树。(除根节点和叶子结点外)

 所有叶节点具有相同的深度,等于树高 h。

 每个叶子节点最少包含一个key和两个指针,最多包含2d-1个key和2d个指针。

B+ Tree

 内节点不存储data,只存储key。

 叶子节点不存储指针。

MySQL 索引实现

 MyISAM 索引文件和数据文件是分离,非聚集索引。

 InnoDB 叶节点包含了完整的数据记录,聚集索引。根据主键聚集。

表中有大字段X(例如:text类型),且字段X不会经常更新,以读为为主,请问

(1)、您是选择拆成子表,还是继续放一起;
(2)、写出您这样选择的理由。
拆带来的问题:连接消耗 + 存储拆分空间;不拆可能带来的问题:查询性能;
如果能容忍拆分带来的空间问题,拆的话最好和经常要查询的表的主键在物理结构上放置在一起(分区)
顺序IO,减少连接消耗,最后这是一个文本列再加上一个全文索引来尽量抵消连接消耗
如果能容忍不拆分带来的查询性能损失的话:上面的方案在某个极致条件下肯定会出现问题,那么不拆就是最好的选择

18、MySQL中InnoDB引擎的行锁是通过加在什么上完成(或称实现)的?为什么是这样子的?
InnoDB是基于索引来完成行锁
例: select * from tab_with_index where id = 1 for update;
for update 可以根据条件来完成行锁锁定,并且 id 是有索引键的列,
如果 id 不是索引键那么InnoDB将完成表锁,,并发将无从谈起

存储引擎

各种存储引擎的区别与联系   
 
(存储数据技术和策略,存储机制、索引技巧、锁定水平等)

数据库存储引擎 
   show table status 显示表的相关信息

InnoDB与MyISAM的比较(从5.7开始innodb存储引擎成为默认的存储引擎。)

 锁机制:行级锁,表级锁

 事务操作:事务安全,不支持

InnoDB
(1)可靠性要求比较高,要求事务;(2)表更新和查询都相当的频繁,并且行锁定的机会比较大的情况。

 MySQL4.1之后每个表的数据和索引存储在一个文件里。

 InnoDB
采用了MVCC来支持高并发,并且实现了四个标准的隔离级别。其默认级别是REPEATABLE
READ(可重复读) ,行级锁。

 自动灾难恢复。与其它存储引擎不同,InnoDB表能够自动从灾难中恢复。

 外键约束。MySQL支持外键的存储引擎只有InnoDB。

 支持自动增加列AUTO_INCREMENT属性。

MyIsam  (1)做很多count
的计算;(2)插入不频繁,查询非常频繁;(3)没有事务。

 表存储在两个文件中,数据文件(MYD)和索引文件(MYI)

 表级锁,读=共享锁,写=排它锁。

 适合选择密集型的表,插入密集型的表。

innodb的事务与日志的实现方式

(1)、有多少种日志;

  • 错误日志:记录出错信息,也记录一些警告信息或者正确的信息。
  • 查询日志:记录所有对数据库请求的信息,不论这些请求是否得到了正确的执行。
  • 慢查询日志:设置一个阈值,将运行时间超过该值的所有SQL语句都记录到慢查询的日志文件中。
  • 二进制日志binlog:记录对数据库执行更改的所有操作。
  • 中继日志relay log:
  • 事务日志 redo log / undo log:

(2)、事物的4种隔离级别

  • 读未提交(RU)
  • 读已提交(RC)
  • 可重复读(RR)
  • 串行

(3)、事务是如何通过日志来实现的,说得越深入越好。
事务日志是通过redo和innodb的存储引擎日志缓冲(Innodb log
buffer)来实现的,当开始一个事务的时候,会记录该事务的lsn(log sequence
number)号; 当事务执行时,会往InnoDB存储引擎的日志
的日志缓存里面插入事务日志;当事务提交时,必须将存储引擎的日志缓冲写入磁盘(通过innodb_flush_log_at_trx_commit来控制),也就是写数据前,需要先写日志。这种方式称为“预写日志方式”

索引类型:

 B-Tree索引 索引列的顺序影响者是否使用索引。

 哈希索引

 无法用于排序。

 只支持全部匹配。

 只支持等值比较。

 有很多哈希冲突时,效率不太高。

 空间数据索引(R-Tree)无需前缀查询,从所有维度查询数据。

 全文检索 查找文本中的关键词,类似于搜索引擎做的事情。

MySQL binlog的几种日志录入格式以及区别

(1)、binlog的日志格式的种类和分别
(2)、适用场景;
(3)、结合第一个问题,每一种日志格式在复制中的优劣。

  • Statement:
    每一条会修改数据的sql都会记录在binlog中,过程导向(没有关注结果)。
    优点:记录sql语句上下文相关信息
    缺点:存储过程,或function,以及trigger的调用和触发无法被正确复制
  • Row:
    不记录sql语句上下文相关信息,仅保存哪条记录被修改成什么样子,结果导向(不关注过程)。
    优点:仅需要记录那一条记录被修改成什么了。所以会非常清楚的记录下每一行数据修改的细节。
    缺点:产生大量的日志内容。
  • Mixedlevel:
    是以上两种level的混合使用,一般的语句修改使用statment格式保存binlog,如一些函数,statement无法完成主从复制的操作,则
    采用row格式保存binlog,MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式

备份

数据备份(深入浅出Mysql 27章 备份与恢复)

 全备份与增量备份的比较。

 确保 MySQL 打开 log-bin 选项,有了 BINLOG,MySQL
才可以在必要的时候做完 整恢复,或基于时间点的恢复,或基于位置的恢复。

逻辑备份(将数据库中的数据备份为一个文本文件,备份的文件可以被查 看和编辑。)

物理备份

 冷备份:cp移动数据文件的方法。

 恢复:移动数据文件,使用 mysqlbinlog 工具恢复自备份以来的所有
BINLOG。

 热备份:(将要备份的表加读锁,然后再 cp 数据文件到备份目录。)

 MyISAM:mysqlhotcopy工具。

 ibbackup 是 Innobase 公司(www.innodb.com)的一个热备份工具。

mysql中myisam与innodb的区别

EXPLAIN 字段介绍

 possible_keys:显示可能应用在这张表中的索引。

 key:实际使用的索引。

 key_len:使用的索引的长度,越短越好。

 ref:显示索引的哪一列被使用了。

 rows:MySQL认为必须检索的用来返回请求数据的行数。

 type:使用了何种类型。从最好到最差的连接类型为system、const(常量)、eq_ref、ref、range、index(索引全表扫描)和ALL(全表扫描)。

备份计划,mysqldump以及xtranbackup的实现原理

(1)、备份计划;
利用空闲间隔
长期全量备份
每天增量备份
删除1个月前的备份数据

(2)、备份恢复时间;
(3)、xtrabackup实现原理
在InnoDB内部会维护一个redo日志文件,我们也可以叫做事务日志文件。事务日志会存储每一个InnoDB表数据的记录修改。当InnoDB启动时,InnoDB会检查数据文件和事务日志,并执行两个步骤:它应用(前滚)已经提交的事务日志到数据文件,并将修改过但没有提交的数据进行回滚操作。

Mysql死锁问题

Mysql悲观锁总结和实践

Mysql乐观锁总结和实践

SELECT … LOCK IN SHARE MODE SELECT … FOR UPDATE:(LOCK IN SHARE
MODE 在有一方事务要Update 同一个表单时很容易造成死锁)

乐观锁:取锁失败,产生回溯时影响效率。

 取数据时认为其他线程不会对数据进行修改。

 更新时判断是否对数据进行修改,版本号机制或CAS操作。

悲观锁:每次取数据都会加锁。

innodb_lock_wait_timeout 等待锁超时回滚事务:  【超时法】

直观方法是在两个事务相互等待时,当一个等待时间超过设置的某一阀值时,对其中一个事务进行回滚,另一个事务就能继续执行。在innodb中,参数innodb_lock_wait_timeout用来设置超时时间。

wait-for graph算法来主动进行死锁检测:  【等待图法】

innodb还提供了wait-for
graph算法来主动进行死锁检测,每当加锁请求无法立即满足需要并进入等待时,wait-for
graph算法都会被触发。

MySQL数据库cpu飙升到500%的话他怎么处理?

(1)、没有经验的,可以不问;
(2)、有经验的,问他们的处理思路。

  • 找出占用的线程杀掉,分析日志,找问题,解决
  • mysql> show processlist; 找出占用cpu的线程
  • 常见问题 :
    1. 睡眠连接过多,严重消耗mysql服务器资源(主要是cpu,
      内存),并可能导致mysql崩溃。
      解决办法 :
      mysql的配置my.ini文件中wait_timeout,
      即可设置睡眠连接超时秒数,如果某个连接超时,会被mysql自然终止。
      mysql> set global wait_timeout=20;
    2. 增加 tmp_table_size 值
    3. SQL语句没有建立索引
    4. 函数计算的,放到应用层进行

索引

索引(存储引擎 快速找到记录的一种数据结构,索引的基本功能)

什么是B-Tree

MySQL索引背后的数据结构及算法原理

MySQL性能优化-慢查询分析、优化索引和配置

开放性问题:

一个6亿的表a,一个3亿的表b,通过外间tid关联,你如何最快的查询出满足条件的第50000到第50200中的这200条数据记录
1、如果A表TID是自增长,并且是连续的,B表的ID为索引
select * from a,b where a.tid = b.id and a.tid>500000 limit 200;
2、如果A表的TID不是连续的,那么就需要使用覆盖索引.TID要么是主键,要么是辅助索引,B表ID也需要有索引。
select * from b , (select tid from a limit 50000,200) a where b.id = a
.tid;

数据库ACID

数据库的ACID

数据库事务介绍

原子性(Atomicity)一个事务必须被视为一个不可分割的最小工作单元,整个事务中的所有操作要么全部提交成功,要么全部失败回滚,对于一个事务来说,不可能只执行其中的一部分操作。

一致性(Consistency)数据库总是从一个一致性的状态转换到另一个一致性的状态。

隔离性(Isolation)一个事务所做的修改在最终提交以前,对其他事务是不可见的。

持久性(Durability)一旦事务提交,则其所做的修改不会永久保存到数据库。

4 种隔离级别

MVVC的简单介绍

READ
UNCOMMITTED(未提交读)脏读
:事务中的修改,即使没有提交,对其他事务也都是可见的。

READ
COMMITTED(提交读)不可重复读
:事务从开始直到提交之前,所做的任何修改对其他事务都是不可见的。

REPEATABLE
READ(可重复读):幻读:
一个事务按相同的查询条件读取以前检索过的数据,其他事务插入了满足其查询条件的新数据。产生幻行。

SERIALIZABLE(可串行化) 强制事务串行执行

MVVC是个行级锁的变种,它在普通读情况下避免了加锁操作,自特定情况下加锁

2者selectcount(*)哪个更快,为什么

myisam更快,因为myisam内部维护了一个计数器,可以直接调取。

发表评论

电子邮件地址不会被公开。 必填项已用*标注