阜阳h5网站建设公司,如何评估一个网站,公司网站建设开发,上国外网站哪个dns快1.mysql语句执行的步骤 客户端请求-连接器#xff08;验证用户身份#xff0c;给与权限#xff09;查询缓存#xff08;存在缓存则直接返回#xff0c;不存在则执行后续操作#xff09;分析器#xff08;对sql进行词法分析和语法分析操作#xff09;优化器#x…1.mysql语句执行的步骤 客户端请求-连接器验证用户身份给与权限查询缓存存在缓存则直接返回不存在则执行后续操作分析器对sql进行词法分析和语法分析操作优化器主要对执行的sql优化选择最优的执行方案方法执行器执行时会先看用户是否有执行权限有才去使用这个引擎提供的接口-去引擎层获取数据返回如果开启查询缓存则会缓存查询结果 2.mysql有哪几种锁 表级锁开销小加锁快不会出现死锁锁粒度大发生锁冲突的概率最高并发度最低行级锁开销大加锁慢会出现死锁锁粒度最小发生锁冲突的概率最低并发度最高页面锁开销和加锁时间界于表锁和行锁之间会出现死锁 3.mysql中不同的表格 myisamheapmergeinnodbisam 4.myisam和innodb的区别 myisam 不支持事务但每次查询都是原子的支持表级锁即每次操作是对整个表加锁存储表的总行数一个Myisam表有三个文件索引文件表结构文件数据文件采用非聚集索引索引文件的数据域存储指向数据文件的指针辅索引与主索引基本一致但是辅索引不用保证唯一性 innodb 支持acid事务支持事务的四种隔离级别支持行级锁及外键约束因此可以支持写并发不存储总行数一个innodb引擎存储在一个文件空间共享表空间表大小不受操作系统控制一个表可能分布在多个文件里也有可能为多个受操作系统文件大小的限制。主键索引采用聚集索引辅索引的数据域存储主键的值因此从辅助索引查找数据需要先通过辅索引找到主键值再访问辅索引最好使用自增主键防止插入数据时为维持B树结构文件的大调整。 5.四种隔离级别 read uncommitted读到未提交数据read committed不可重复读repeatable read可重复读serializable串行 6.mysql数据库作发布系统的存储一天五万条以上的增量预计运维三年怎么优化 设计良好的数据库结构允许部分数据冗余尽量避免join查询提高效率选择合适的表字段数据类型和存储引擎适当添加索引mysql库主从读写分离找规律分表减少单表中的数据量提高查询速度添加缓存机制比如memcachedapc等不经常改动的页面生成静态页面书写高效率sql。 7.锁的优化策略 读写分离分段加锁减少锁持有时间多个线程尽量以相同的顺序去获取资源 不能将锁的粒度过于细化不然可能会出现线程的加锁和释放次数过多反而效率不如一次加一把大锁 8.索引的底层实现原理和优化 B树。主要是在所有叶子结点中增加了指向下一个叶子节点的指针使用默认自增的主键作为主索引。 索引常见底层数据结构 哈希表有序数据组搜索树 哈希表等值查询场景egmemcached和其他一些nosql引擎不适合范围查询有序数组索引只适用于静态存储引擎等值和范围查询性能好但更新数据成本高N叉树由于读写上的性能有点和适配磁盘访问模式以及广泛应用在数据库引擎中扩展 索引类型 主键索引叶子节点存的整行数据在innodb里也被称为聚簇索引非主键索引叶子节点存的主键的值在innodb里也被称为二级索引 innodb B树索引 考虑因素 innodb需要执行的场景和功能需要在特定查询上拥有较强的性能cpu将磁盘上的数据加载到内存中需要花费大量时间 选择原因 哈希索引虽然能提供O1复杂度查询但对范围查询和排序却无法很好的支持最终会导致全表扫描B树能够在非叶子节点存储数据但会导致在查询连续数据可能带来更多的随机IOB树的所有叶子节点可以通过指针来相互连接减少顺序遍历带来的随机IO由于唯一索引用不上change buffer的优化机制如果业务可以接受从性能角度出发建议优先考虑非唯一索引 9.覆盖索引和索引下推 覆盖索引 在某个查询里面索引 k 已经“覆盖了”查询需求称为覆盖索引。覆盖索引可以减少树的搜索次数显著提升查询性能所以使用覆盖索引是一个常用的性能优化手段。 索引下推 MySQL 5.6 引入的索引下推优化index condition pushdown) 可以在索引遍历过程中对索引中包含的字段先做判断直接过滤掉不满足条件的记录减少回表次数。 10.索引失效 对索引使用左或者左右模糊匹配也就是 like %xx 或者 like %xx% 这两种方式都会造成索引失效。原因在于查询的结果可能是多个不知道从哪个索引值开始比较于是就只能通过全表扫描的方式来查询。对索引进行函数/对索引进行表达式计算因为索引保持的是索引字段的原始值而不是经过函数计算的值自然就没办法走索引。对索引进行隐式转换相当于使用了新函数。WHERE 子句中的 OR语句只要有条件列不是索引列就会进行全表扫描。 11…优化mysql sql语句及索引的优化数据库表结构的优化系统配置的优化硬件的优化 12.优化数据库 选取最适用的字段属性尽可能减少定义字段宽度尽量把字段设置NOTNULL例如省份性别最好适用ENUM使用连接join来代替子查询使用联合union来代替手动创建的临时表事务处理锁定表、优化事务处理适用外键优化锁定表建立索引优化查询语句 13.索引主键唯一索引联合索引区别对数据库性能有什么影响 索引是一种特殊的文件包含对数据表里所有记录的引用指针。 普通索引的唯一任务就是加快对数据的访问速度。允许被索引的数据列包含重复的值如果能确定某个数据列将只包含彼此各不相同的值为这个数据列创建索引的时候就应该用关键字unique把它定义为一个唯一索引即唯一索引可以保证数据记录的唯一性。主键一种特殊的唯一索引在一张表中只能定义一个主键索引用于唯一标识一条记录primary key来创建联合索引索引可以覆盖多个数据列eg:INDEX(columnA,columnB)索引 索引可以极大的提高数据的查询速度但会降低插入、删除、更新表的速度因此在执行这些写操作时还要操作索引文件。 14.数据库事务 特性原子性一致性隔离性持久性 15.索引 目的 快速访问表的特定信息提高检索速度创建唯一性索引保证数据表中每行数据的唯一性加速表和表之间的链接使用分组和排序子句进行数据检索时可以显著减少查询中分组和排序的时间。 缺点 创建索引和维护索引需要耗费时间这个时间随数据量增加而增加索引需要占用物理空间当对表进行增删改的时候索引页需要动态维护降低了数据的维护速度 建立原则 在最频繁使用的用以缩小查询范围的字段上建立索引在频繁使用的需要排序的字段上建立索引 不适合建立索引 查询中很少涉及的列或者重复值比较多的列对于特殊的数据类型不宜建立索引egtextdeng 16.mysql外连接内连接自连接区别 交叉连接笛卡尔积不使用任何条件直接将一个表的所有记录和另一个表中的所有记录一一匹配 内连接只有条件的交叉连接根据某个条件筛选出符合条件的记录不符合条件的记录不会出现在结果集中内连接只连接匹配的行 外连接结果集中不仅包含符合连接条件的行而且还会包含左表右表或两个表中的所有数据行依次称 左外链接左连接左表为主表左表中所有记录都会出现在结果集中对于右表中没有匹配的记录仍要显示右外连接右连接右表为主表右表中所有记录都会出现在结果集中全外连接mysql目前不支持全外连接 17.数据完整性指数据的精确性和可靠性 实体完整性规定表中的每一行在表中是唯一的实体域完整性指表中的列必须满足某种特定的数据类型约束其中约束包括取值范围、精度等规定参照完整性指两个表的主关键字和外关键字的数据应一致保证了表之前的数据一致性防止了数据丢失和无意义的数据在数据库中扩散用户定义的完整性不同的关系数据库系统根据其应用环境的不同往往还需要一些特殊的约束条件用户定义的完整性即是针对某个特定关系数据库的约束条件反映了某一具体应用必须满足的语义要求 与表有关的约束为包括列约束not null 表约束primary keyforeign keycheckunique 18.视图游标 视图一种虚拟的表具有和物理表相同的功能可以对视图进行增改查操作视图通常是有一个表或者多个表的行或列的子集对视图的修改不影响基本表使得我们获取数据更容易 游标是对查询出来的结果集作为一个单元来有效的处理游标可以定在该单元中的特定行从结果集的当前行检索一行或多行可以对结果集当前行做修改。一般不使用游标但是需要逐条处理数据的时候游标很重要。 19.存储过程 存储过程是一个预编译的sql语句优点是允许模块化设计只需要创建一次以后在该程序中就可以调用多次如果某次操作需要执行多次sql使用存储过程比单纯sql语句执行要快可以用一个命令对象来调用存储过程。 20.基本表视图 基本表是本身独立存在的表在sql中一个关系就对应一个表 视图是从一个或几个基本表导出的表视图本身不独立存储在数据库中是一个虚表 21.视图优点 视图能够简化用户的操作视图使用户能以多种角度看待同一数据视图为数据库提供了一定程度的逻辑独立性视图能够对机密数据提供安全保护 22主键外键索引 主键唯一标识一条记录不能有重复的不允许为空—保证数据完整性 — 只能一个外键另一个表的主键外键可以有重复的可以是空值 — 用来和其他表建立联系用的 — 可以有多个外键索引没有重复值但有个空值 — 提高查询排序的速度 — 可以有多个索引 23sql优化 where子句表之间的连接必须写在其他where条件之前那些可以过滤掉最大数量记录的条件必须写在where子句的末尾having最后用exists替代in用not exists 替代not in避免在索引列上使用计算避免在索引上使用is null 和is not null对查询进行优化避免全表扫描考虑在where及order by 涉及的列上建立索引尽量避免在where子句中对字段进行null值判断否则将导致引擎放弃使用索引而进行全表扫描尽量避免在where子句中对字段进行表达式操作将导致引擎放弃使用索引而进行全表扫描 索引 InnoDB 存储引擎的默认索引实现为B 树索引。 自增主键 使用自增主键那么每次插入新的记录记录就会顺序添加到当前索引节点的后续位置当一页写满就会自动开辟一个新的页。如果使用非自增主键如果身份证号或学号等由于每次插入主键的值近似于随机因此每次新纪录都要被插到现有索引页得中间某个位置 频繁的移动、分页操作造成了大量的碎片得到了不够紧凑的索引结构后续不得不通过OPTIMIZE TABLEoptimize table来重建表并优化填充页面。 聚簇索引 聚簇索引就是按照每张表的 主键 构造一棵B树同时叶子节点中存放的就是整张表的行记录数据。 在 InnoDB 中只有主键索引是聚簇索引如果没有主键则挑选一个唯一键建立聚簇索引。如果没有唯一键则MySQL自动为InnoDB表生成一个隐含字段来建立聚簇索引这个字段长度为6个字节类型为长整形。 当查询使用聚簇索引时在对应的叶子节点可以获取到整行数据因此不用再次进行回表查询。 聚簇索引叶子节点存放的是主键值和数据行支持覆盖索引innodb的是主键索引使用的是聚簇索引非聚簇索引叶子节点存放的是主键值或数据记录的地址myisam使用的都是非聚簇索引 根据主键索引搜索时直到找到key所在的节点即可取出数据根据辅助索引查找时则需要先取出主键的值再走一遍主索引。 非聚簇索引不一定会回表查询如果查询语句全部命中索引则不必再进行回表查询 索引底层实现 hash索引 基于哈希表实现只有精确匹配索引所有列的查询才有效对于每一行数据存储引擎都会对所有的索引列计算一个哈希码hash code并且Hash索引将所有的哈希码存储在索引中同时在索引表中保存指向每个数据行的指针。 B树索引数据库索引所采用的存储结构。数据都在叶子节点上并且增加了顺序访问指针每个叶子节点都指向相邻的叶子节点的地址。相比B-Tree来说进行范围查找时只需要查找两个节点进行遍历即可。而B-Tree需要获取所有节点相比之下BTree效率更高。 n棵子tree的节点包含n个关键字不用来保存数据而是保存数据的索引。所有的叶子结点中包含了全部关键字的信息及指向含这些关键字记录的指针且叶子结点本身依关键字的大小自小而大顺序链接。所有的非终端结点可以看成是索引部分结点中仅含其子树中的最大或最小关键字。B 树中数据对象的插入和删除仅在叶节点上进行。B树有2个头指针一个是树的根节点一个是最小关键码的叶节点。 使用b树原因B树只要遍历叶子节点就可以实现整棵树的遍历而且在数据库中基于范围的查询是非常频繁的而B树只能中序遍历所有节点效率太低。 创建的索引有没有被使用到或者怎么才能知道这条语句运行很慢的原因 用explain命令查看语句的执行计划mysql执行语句前会将该语句过一遍查询优化器之后会拿到对语句的分析即执行计划其中包含许多信息可以通过其中和索引相关的信息来分析是否命中了索引。 创建了索引但查询是并没有使用的情况 使用不等于查询列参与了数学运算或者函数在字符串 like 时左边是通配符。类似于’%aaa’。当 mysql 分析全表扫描比使用索引快的时候不使用索引。当使用联合索引前面一个条件为范围查询后面的即使符合最左前缀原则也无法使用索引。 索引种类 普通索引最基本的索引它没有任何限制值可以为空仅加速查询唯一索引与普通索引类似不同的就是索引列的值必须唯一但允许有空值。如果是组合索引则列值的组合必须唯一。简单来说唯一索引是加速查询 列值唯一可以有null主键索引一种特殊的唯一索引一个表只能有一个主键不允许有空值。简单来说主键索引是加速查询 列值唯一不可以有null 表中只有一个。组合索引指在多个字段上创建的索引只有在查询条件中使用了创建索引时的第一个字段索引才会被使用。使用组合索引时遵循最左前缀集合。全文索引用来查找文本中的关键字而不是直接与索引中的值相比较。fulltext索引跟其它索引大不相同它更像是一个搜索引擎而不是简单的where语句的参数匹配。fulltext索引配合match against操作使用而不是一般的where语句加like。它可以在create tablealter table create index使用不过目前只有char、varchartext 列上可以创建全文索引。值得一提的是在数据量较大时候现将数据放入一个没有全局索引的表中然后再用CREATE index创建fulltext索引要比先为一张表建立fulltext然后再将数据写入的速度快很多。 适合索引 字段有唯一性限制经常用于where查询条件的字段经常用于group by和order by的字段 不需要创建索引 wheregroup byorder by 里用不到的字段字段中存在大量重复数据不需要创建索引表数据太少不需要创建索引经常更新的字段不用创建索引 索引失效 模糊查询:like ‘%’like %%通配符放在开头会导致索引失效。会进行全表扫描索引类使用函数带有函数的索引列记录的是索引的原始值不是计算后的值所以mysql不会识别在mysql8.0增加了函数索引用来解决这一问题。数据类型发生转换当字符类型没有使用引号的时候mysql会自动将字符转换成数字会用到隐式转换相当于使用了函数。但是在8.0函数索引中会不会有效还没研究WHERE 子句中使用OR连接当or前后都是索引列的时候不会导致索引失效但当or前后有一个不是索引列的时候索引就会失效原因是当使用or的时候有一个条件不满足就会进行全面扫描。多列组成组合索引需要遵循最左匹配原则从索引最左侧顺序进行检索在组合索引中是按照列的顺序进行存储的所以查的时候也需要按照顺序查。索引列使用运算符或者not类似使用函数。多表连接查询没有正确使用mysql规则也会导致索引失效。 索引优化 前缀索引优化使用某个字段中字符串的前几个字符建立索引 减小索引字段大小可以增加一个索引页中存储的索引值有效提高索引的查询速度。一些大字符串的字段作为索引时使用前缀索引可以减小索引项的大小。局限性order by 就无法使用前缀索引无法把前缀索引用作覆盖索引 覆盖索引优化SQL 中 query 的所有字段在索引 BTree 的叶子节点上都能找得到的那些索引从二级索引中查询得到记录而不需要通过聚簇索引查询获得可以避免回表的操作。主键索引最好是自增的InnoDB 创建主键索引默认为聚簇索引数据被存放在了 BTree 的叶子节点上。同一个叶子节点内的各个数据是按主键顺序存放的每当有一条新的数据插入时数据库会根据主键将其插入到对应的叶子节点中。 使用自增主键每次插入的新数据就会按顺序添加到当前索引节点的位置不需要移动已有的数据当页面写满就会自动开辟一个新页面。因为每次插入一条新记录都是追加操作不需要重新移动数据因此这种插入数据的方法效率非常高。使用非自增主键由于每次插入主键的索引值都是随机的因此每次插入新的数据时就可能会插入到现有数据页中间的某个位置这将不得不移动其它数据来满足新数据的插入甚至需要从一个页面复制数据到另外一个页面我们通常将这种情况称为页分裂。页分裂还有可能会造成大量的内存碎片导致索引结构不紧凑从而影响查询效率。索引最好设置为not null 索引列存在 NULL 就会导致优化器在做索引选择的时候更加复杂更加难以优化因为可为 NULL 的列会使索引、索引统计和值比较都更复杂比如进行索引统计时count 会省略值为NULL 的行。NULL 值是一个没意义的值但是它会占用物理空间所以会带来的存储空间的问题会导致更多的存储空间占用因为 InnoDB 默认行存储格式COMPACT会用 1 字节空间存储 NULL 值列表 防止索引失效用上了索引并不意味着查询的时候会使用到索引避免写出索引失效的查询语句否则这样的查询效率是很低的。可以使用explain查看执行计划 事务相关 特性 AAtomicity原子性就是要么全部成功要么全部失败。不可能只执行一部分操作。CConsistency一致性系统(数据库)总是从一个一致性的状态转移到另一个一致性的状态不会存在中间状态。IIsolation隔离性通常来说一个事务在完全提交之前对其他事务是不可见的.有例外情况。DDurability持久性一旦事务提交那么就永远是这样子了哪怕系统崩溃也不会影响到这个事务的结果。 事务回滚机制 恢复机制是通过回滚日志undo log实现的所有事务进行的修改都会先记录到这个回滚日志中然后在对数据库中的对应行进行写入。当事务已经被提交之后就无法再次回滚了。 作用 能够在发生错误或者用户执行 ROLLBACK 时提供回滚相关的信息在整个系统发生崩溃、数据库进程直接被杀死后当用户再次启动数据库进程时还能够立刻通过查询回滚日志将之前未完成的事务进行回滚这也就需要回滚日志必须先于数据持久化到磁盘上是我们需要先写日志后写数据库的主要原因。 数据库并发事务会带来的问题 脏读A 事务读取到了 B 事务未提交的内容但是之后B事务满足一致性等特性而做了回滚操作那么读取事务得到的结果就是脏数据了。幻读A 事务读取了一个范围的内容而同时 B 事务在此期间插入删除了一条数据。造成幻觉。丢弃修改两个写事务T1 T2同时对A0进行递增操作结果T2覆盖T1导致最终结果是1 而不是2事务被覆盖不可重复读当设置T2事务只能读取 T1 事务已经提交的部分T2 读取一个数据然后T1 对该数据做了修改。如果 T2 再次读取这个数据此时读取的结果和第一次读取的结果不同。 四种隔离级别 未提交读(READ UNCOMMITTED)事务中发生了修改即使没有提交其他事务也是可见的比如对于一个数A原来50修改为100但是我还没有提交修改另一个事务看到这个修改而这个时候原事务发生了回滚这时候A还是50但是另一个事务看到的A是100.可能会导致脏读、幻读或不可重复读已提交读(READ COMMITTED)对于一个事务从开始直到提交之前所做的任何修改是其他事务不可见的举例就是对于一个数A原来是50然后提交修改成100这个时候另一个事务在A提交修改之前读取的A是50刚读取完A就被修改成100这个时候另一个事务再进行读取发现A就突然变成100了可以阻止脏读但是幻读或不可重复读仍有可能发生可重复读(REPEATABLE READ)就是对一个记录读取多次的记录是相同的比如对于一个数A读取的话一直是A前后两次读取的A是一致的可以阻止脏读和不可重复读但幻读仍有可能发生可串行化(SERIALIZABLE)在并发情况下和串行化的读取的结果是一致的没有什么不同比如不会发生脏读和幻读该级别可以防止脏读、不可重复读以及幻读 不可重复读的重点是修改幻读的重点在于新增或者删除。 innodb默认支持repeatable-read可重复读加锁算法可以避免幻读产生 锁分类 按锁粒度分 行锁: 描述mysql中锁定粒度最细的一种锁。表示只针对当前操作的行进行加锁。行级锁能大大减少数据库操作的冲突其加锁粒度最小但加锁的开销也最大。行级锁分为共享锁和排他锁特点开销大加锁慢会出现死锁。发生锁冲突的概率最低并发度也最高。 表锁 描述mysql中锁定粒度最大的一种锁表示对当前操作的整张表加锁它实现简单资源消耗较少被大部分mysql引擎支持。最常使用的MyISAM与InnoDB都支持表级锁定。表级锁定分为表共享读锁共享锁与表独占写锁排他锁特点 开销小加锁快不会出现死锁。发生锁冲突的概率最高并发度也最低。 页锁 描述 MySQL 中锁定粒度介于行级锁和表级锁中间的一种锁。表级锁速度快但冲突多行级冲突少但速度慢。因此采取了折衷的页级锁一次锁定相邻的一组记录。BDB 支持页级锁。特点开销和加锁时间界于表锁和行锁之间会出现死锁锁定粒度界于表锁和行锁之间并发度一般。 按使用方式分 共享锁 描述共享锁又称读锁是读取操作创建的锁。其他用户可以并发读取数据但任何事务都不能对数据进行修改获取数据上的排他锁直到已释放所有共享锁。 如果事务T对数据A加上共享锁后则其他事务只能对A再加共享锁不能加排他锁。获取共享锁的事务只能读数据不能修改数据。用法SELECT … LOCK IN SHARE MODE; 在查询语句后面增加LOCK IN SHARE MODEMySQL 就会对查询结果中的每行都加共享锁当没有其他线程对查询结果集中的任何一行使用排他锁时可以成功申请共享锁否则会被阻塞。其他线程也可以读取使用了共享锁的表而且这些线程读取的是同一个版本的数据。 排它锁 描述排他锁又称写锁、独占锁如果事务T对数据A加上排他锁后则其他事务不能再对A加任何类型的封锁。获取排他锁的事务既能读数据又能修改数据。用法SELECT … FOR UPDATE; 在查询语句后面增加FOR UPDATEMySQL 就会对查询结果中的每行都加排他锁当没有其他线程对查询结果集中的任何一行使用排他锁时可以成功申请排他锁否则会被阻塞。 按思想分 乐观锁假设不会发生并发冲突只在提交操作时检查是否违反数据完整性。 乐观锁不能解决脏读的问题。每次去拿数据的时候都认为别人不会修改所以不会上锁但是在更新的时候会判断一下在此期间别人有没有去更新这个数据可以使用版本号等机制。乐观锁适用于多读的应用类型这样可以提高吞吐量像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。悲观锁假定会发生并发冲突屏蔽一切可能违反数据完整性的操作。每次去拿数据的时候都认为别人会修改所以每次在拿数据的时候都会上锁这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制比如行锁表锁等读锁写锁等都是在做操作之前先上锁。场景 悲观锁先获取锁再进行业务操作一般就是利用类似 SELECT … FOR UPDATE 这样的语句对数据加锁避免其他事务意外修改数据。当数据库执行SELECT … FOR UPDATE时会获取被select中的数据行的行锁select for update获取的行锁会在当前事务结束时自动释放因此必须在事务中使用。乐观锁先进行业务操作只在最后实际更新数据时进行检查数据是否被更新过。Java 并发包中的 AtomicFieldUpdater 类似也是利用 CAS 机制并不会对数据加锁而是通过对比数据的时间戳或者版本号来实现乐观锁需要的版本判断。 用存储引擎的锁机制 MyISAM和MEMORY采用表级锁(table-level locking)BDB采用页面锁(page-level locking)或表级锁默认为页面锁InnoDB支持行级锁(row-level locking)和表级锁,默认为行级锁 存储引擎有几种锁算法 Record Lock — 单个行记录上的锁Gap Lock — 间隙锁锁定一个范围不包括记录本身Next-Key Lock — 锁定一个范围包括记录本身。 死锁 是指二个或者二个以上的进程在执行时候因为争夺资源造成相互等待的现象进程一直处于等待中无法得到释放这种状态就叫做死锁。案例批量入库存在则更新不存在则插入insert into tab(xx,xx) on duplicate key update xx‘xx’。处理 通过innodblockwait_timeout来设置超时时间一直等待直到超时发起死锁检测发现死锁之后主动回滚死锁中的事务不需要其他事务继续 避免 为了在单个innodb表上执行多个并发写入操作时避免死锁可以在事务开始时通过为预期要修改行使用select …for update语句来获取必要的锁即使这些行的更改语句是在之后才执行的在事务中如果要更新记录应该直接申请足够级别的锁即排他锁而不应先申请共享锁更新时在申请排他锁。因为这时候当用户在申请排他锁时其他事务可能又已经获得了相同记录的共享锁如果事务需要修改或锁定多个表则应在每个事务中以相同的顺序使用加锁语句。在应用中如果不同的程序会并发获取多个表应尽量约定以相同的顺序来访问表这样可以大大降低产生死锁的机会通过 select …lock in share mode获取行的读锁后如果当前事务在需要对该记录进行更新操作则很有可能造成死锁改变事务隔离级别 innodb处理死锁设置死锁时间来让死锁超时的策略默认innodblockwait_timeout设置的时长是50s开启死锁检测设置innodbdeadlockdetect设置为on可以主动检测死锁在innodb中这个值默认就是on开启的状态全局锁应用场景 对整个数据库实例加锁做全库逻辑备份这个命令可以使用整个库处于只读状态使用该命令之后数据更新语句数据定义语句更新类事务的提交语句等操作都会被阻塞。导致的问题 如果在主库备份在备份期间不能更新业务停止所以更新业务会处于等待状态如果在从库备份在备份期间不能执行主库同步的binlog导致主从延迟 优化锁 尽量使用较低的隔离级别。精心设计索引 并尽量使用索引访问数据 使加锁更精确 从而减少锁冲突的机会。选择合理的事务大小小事务发生锁冲突的几率也更小。给记录集显示加锁时最好一次性请求足够级别的锁。比如要修改数据的话最好直接申请排他锁而不是先申请共享锁修改时再请求排他锁这样容易产生死锁。不同的程序访问一组表时应尽量约定以相同的顺序访问各表对一个表而言尽可能以固定的顺序存取表中的行。这样可以大大减少死锁的机会。尽量用相等条件访问数据这样可以避免间隙锁对并发插入的影响。不要申请超过实际需要的锁级别。除非必须查询时不要显示加锁。 MySQL 的 MVCC 可以实现事务中的查询不用加锁优化事务性能MVCC 只在 COMMITTED READ读提交和 REPEATABLE READ可重复读两种隔离级别下工作。对于一些特定的事务可以使用表锁来提高处理速度或减少死锁的可能。 mysql内部构造 服务层连接器查询缓存分析器优化器执行器等存储引擎负责数据的存储和提取 server层按顺序执行sql步骤 1.客户端请求- 2.连接器验证用户身份给予权限 - 3.查询缓存存在缓存则直接返回不存在则执行后续操作- 4.分析器对SQL进行词法分析和语法分析操作 - 5.优化器主要对执行的sql优化选择最优的执行方案方法 - 6.执行器执行时会先看用户是否有执行权限有才去使用这个引擎提供的接口- 7.去引擎层获取数据返回如果开启查询缓存则会缓存查询结果 表结构相关 Drop、Delete与Truncate的共同点和区别 Drop直接删掉表;Truncate删除表中数据再插入时自增长id又从1开始 ;Delete删除表中数据可以加where字句。 MySQL数据库cpu飙升的话要怎么处理 排查过程 使用top 命令观察确定是mysqld导致还是其他原因。如果是mysqld导致的show processlist查看session情况确定是不是有消耗资源的sql在运行。找出消耗高的 sql看看执行计划是否准确 索引是否缺失数据量是否太大。 处理 kill 掉这些线程(同时观察 cpu 使用率是否下降) 进行相应的调整(比如说加索引、改 sql、改内存参数) 重新跑这些 SQL。 mysql主从延迟怎么解决 主从复制五个步骤 步骤一主库的更新事件(update、insert、delete)被写到binlog步骤二从库发起连接连接到主库。步骤三此时主库创建一个binlog dump thread把binlog的内容发送到从库。步骤四从库启动之后创建一个I/O线程读取主库传过来的binlog内容并写入到relay log步骤五还会创建一个SQL线程从relay log里面读取内容从Exec_Master_Log_Pos位置开始执行读取到的更新事件将更新内容写入到slave的db 主从同步延迟的原因 一个服务器开放个链接给客户端来连接的会有大并发的更新操作, 但从服务器的里面读取binlog的线程仅有一个当某个SQL在从服务器上执行的时间稍长 或者由于某个SQL要进行锁表就会导致主服务器的SQL大量积压未被同步到从服务器里。这就导致了主从不一致 也就是主从延迟。 主从同步延迟的解决办法 主服务器要负责更新操作对安全性的要求比从服务器要高所以有些设置参数可以修改比如sync_binlog1innodb_flush_log_at_trx_commit 1 之类的设置等。 选择更好的硬件设备作为slave。 把一台从服务器当度作为备份使用 而不提供查询 那边他的负载下来了 执行relay log 里面的SQL效率自然就高了。 增加从服务器这个目的还是分散读的压力从而降低服务器负载。 分库分表 水平分库以字段为依据按照一定策略hash、range等将一个库中的数据拆分到多个库中。 水平分表以字段为依据按照一定策略hash、range等将一个表中的数据拆分到多个表中。 垂直分库以表为依据按照业务归属不同将不同的表拆分到不同的库中。 垂直分表以字段为依据按照字段的活跃性将表中字段拆到不同的表主表和扩展表中。 分库分表中间件sharding-jdbc、mycat 分库分表的问题 事务问题需要用分布式事务 跨节点Join的问题解决这一问题可以分两次查询实现 跨节点的count,order by,group by以及聚合函数问题分别在各个节点上得到结果后在应用程序端进行合并。 数据迁移容量规划扩容等问题 ID问题数据库被切分后不能再依赖数据库自身的主键生成机制最简单可以考虑UUID 跨分片的排序分页问题 count1、count*、count列名 count(*)包括了所有的列相当于行数在统计结果的时候 不会忽略列值为NULLcount(1)包括了忽略所有列用1代表代码行在统计结果的时候 不会忽略列值为NULLcount(列名)只包括列名那一列在统计结果的时候会忽略列值为空这里的空不是只空字符串或者0而是表示null的计数 即某个字段值为NULL时不统计。 执行效率上 列名为主键count(列名)会比count(1)快 列名不为主键count(1)会比count(列名)快 如果表多个列并且没有主键则 count1 的执行效率优于 count 如果有主键则 select count主键的执行效率是最优的 如果表只有一个字段则 select count最优。 sql中null与空值的区别 占用空间区别空值(’’)的长度是0是不占用空间的而NULL的长度是NULL是占用空间的插入/查询方式区别NULL值查询使用is null/is not null查询而空值(’’)可以使用或者!、、等算术运算符。COUNT 和 IFNULL函数使用 COUNT(字段) 统计会过滤掉 NULL 值但是不会过滤掉空值。索引字段说明在有NULL值的字段上使用常用的索引如普通索引、复合索引、全文索引等不会使索引失效。在官网查看在空间索引的情况下说明了 索引列必须为NOT NULL。 优化 表结构优化 尽量使用数字型字段数值信息的字段不设计为字符型尽可能用varchar代替char变长字段存储空间小节省存储空间当索引列大量重复数据时可以把索引删除掉eg性别字段索引无效 查询优化 应尽量避免在 where 子句中使用!或操作符应尽量避免在 where 子句中使用 or 来连接条件任何查询也不要出现select *避免在 where 子句中对字段进行 null 值判断 索引优化 对作为查询条件和 order by的字段建立索引避免建立过多的索引多使用组合索引 慢查询优化 分析语句是否加载了不必要的字段/数据分析 SQL 执行句话是否命中索引等如果 SQL 很复杂优化 SQL 结构如果表数据量太大考虑分表