MySQL面试题-数据库优化二

叁歲伎倆 2023-07-23 06:55 41阅读 0赞

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ0NTQ1MDgz_size_16_color_FFFFFF_t_70_pic_center]

1.  读写分离有哪些解决方案？  
    读写分离是依赖于主从复制，而主从复制又是为读写分离服务的。因为主从复制要求slave不能写只能读（如果对slave执行写操作，那么show slave status将会呈现Slave\_SQL\_Running=NO，此时你需要按照前面提到的手动同步一下slave）。  
    方案一  
    使用mysql-proxy代理  
    优点：直接实现读写分离和负载均衡，不用修改代码，master和slave用一样的帐号，mysql官方不建议实际生产中使用  
    缺点：降低性能， 不支持事务  
    方案二  
    使用AbstractRoutingDataSource+aop+annotation在dao层决定数据源。  
    如果采用了mybatis， 可以将读写分离放在ORM层，比如mybatis可以通过mybatis plugin拦截sql语句，所有的insert/update/delete都访问master库，所有的select 都访问salve库，这样对于dao层都是透明。plugin实现时可以通过注解或者分析语句是读写方法来选定主从库。不过这样依然有一个问题， 也就是不支持事务， 所以我们还需要重写一下DataSourceTransactionManager， 将read-only的事务扔进读库， 其余的有读有写的扔进写库。  
    方案三  
    使用AbstractRoutingDataSource+aop+annotation在service层决定数据源，可以支持事务.  
    缺点：类内部方法通过this.xx()方式相互调用时，aop不会进行拦截，需进行特殊处理。
2.  备份计划，mysqldump以及xtranbackup的实现原理  
    (1)备份计划  
    视库的大小来定，一般来说 100G 内的库，可以考虑使用 mysqldump 来做，因为 mysqldump更加轻巧灵活，备份时间选在业务低峰期，可以每天进行都进行全量备份(mysqldump 备份出来的文件比较小，压缩之后更小)。  
    100G 以上的库，可以考虑用 xtranbackup 来做，备份速度明显要比 mysqldump 要快。一般是选择一周一个全备，其余每天进行增量备份，备份时间为业务低峰期。  
    (2)备份恢复时间  
    物理备份恢复快，逻辑备份恢复慢  
    这里跟机器，尤其是硬盘的速率有关系，以下列举几个仅供参考  
    20G的2分钟（mysqldump）  
    80G的30分钟(mysqldump)  
    111G的30分钟（mysqldump)  
    288G的3小时（xtra)  
    3T的4小时（xtra)  
    逻辑导入时间一般是备份时间的5倍以上  
    (3)备份恢复失败如何处理  
    首先在恢复之前就应该做足准备工作，避免恢复的时候出错。比如说备份之后的有效性检查、权限检查、空间检查等。如果万一报错，再根据报错的提示来进行相应的调整。  
    (4)mysqldump和xtrabackup实现原理  
    mysqldump  
    mysqldump 属于逻辑备份。加入–single-transaction 选项可以进行一致性备份。后台进程会先设置 session 的事务隔离级别为 RR(SET SESSION TRANSACTION ISOLATION LEVELREPEATABLE READ)，之后显式开启一个事务(START TRANSACTION /\*!40100 WITH CONSISTENTSNAPSHOT \*/)，这样就保证了该事务里读到的数据都是事务事务时候的快照。之后再把表的数据读取出来。如果加上–master-data=1 的话，在刚开始的时候还会加一个数据库的读锁(FLUSH TABLES WITH READ LOCK),等开启事务后，再记录下数据库此时 binlog 的位置(showmaster status)，马上解锁，再读取表的数据。等所有的数据都已经导完，就可以结束事务  
    Xtrabackup:  
    xtrabackup 属于物理备份，直接拷贝表空间文件，同时不断扫描产生的 redo 日志并保存下来。最后完成 innodb 的备份后，会做一个 flush engine logs 的操作(老版本在有 bug，在5.6 上不做此操作会丢数据)，确保所有的 redo log 都已经落盘(涉及到事务的两阶段提交  
    概念，因为 xtrabackup 并不拷贝 binlog，所以必须保证所有的 redo log 都落盘，否则可能会丢最后一组提交事务的数据)。这个时间点就是 innodb 完成备份的时间点，数据文件虽然不是一致性的，但是有这段时间的 redo 就可以让数据文件达到一致性(恢复的时候做的事  
    情)。然后还需要 flush tables with read lock，把 myisam 等其他引擎的表给备份出来，备份完后解锁。这样就做到了完美的热备。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ0NTQ1MDgz_size_16_color_FFFFFF_t_70_pic_center 1]
3.  数据表损坏的修复方式有哪些？  
    使用 myisamchk 来修复，具体步骤：  
    1）修复前将mysql服务停止。  
    2）打开命令行方式，然后进入到mysql的/bin目录。  
    3）执行myisamchk –recover 数据库所在路径/\*.MYI  
    使用repair table 或者 OPTIMIZE table命令来修复，REPAIR TABLE table\_name 修复表 OPTIMIZE TABLE table\_name 优化表 REPAIR TABLE 用于修复被破坏的表。OPTIMIZE TABLE 用于回收闲置的数据库空间，当表上的数据行被删除时，所占据的磁盘空间并没有立即被回收，使用了OPTIMIZE TABLE命令后这些空间将被回收，并且对磁盘上的数据行进行重排（注意：是磁盘上，而非数据库）  
    小编分类整理了许多java进阶学习材料和BAT面试题，需要资料的请加QQ群：731611386就能领取2019年java进阶学习资料和BAT面试题以及《EffectiveJava》（第3版）电子版书籍。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ0NTQ1MDgz_size_16_color_FFFFFF_t_70_pic_center]: /images/20230528/54291681c31e4e50945e19dbc864c03c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ0NTQ1MDgz_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20230528/0b163dfd175249a9955bcf38204b3e7c.png