首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    面了个腾讯35k出来的,他让我见识到什么叫精通MySQL调优

    MySQL调优对于很多程序员而言,都是一个非常棘手的问题,多数情况都是因为对数据库出现问题的情况和处理思路不清晰。在进行MySQL的优化之前必须要了解的就是MySQL的查询过程,很多的查询优化工作实际上就是遵循一些原则让MySQL的优化器能够按照预想的合理方式运行而已。 就在昨天我在百忙之中抽出空余时间面试了个腾讯30k出来的,我开口就是:MYSQL性能调优如何入手?他的回答的:基础优化、优化的哲学、优化需求、优化的思路、存储引擎层、数据库优化、等等细节,好吧我承认我败了。 但是我严重怀疑他是做了准备而来的,不然没有什么人可以记得这么清楚有条理,果不其然,在他入职之后说出了实情;

    04

    MySQL复制性能优化和常见问题分析

    二进制日志文件并不是每次写的时候都会同步到磁盘,当发生宕机的时候,可能会有最后一部分数据没有写入到binlog中,这给恢复和复制带来了问题。当sync_binlog=1表示每写缓冲一次就同步到磁盘,表示同步写磁盘的方式来写binlog。也就是说每当向MySQL提交一次事务,MySQL将进行一次fsync之类的磁盘同步命令来将binlog_cache的数据强制刷到磁盘中sync_binlog的值默认为0,sync_binlog=0时表示采用操作系统机制进行缓冲数据同步。采用sync_binlog=1时,会增加磁盘IO的次数,会影响写入性能。sync_binlog=1时,并不是100%安全,会存在相应的问题。比如说使用Innodb引擎时,在一个事务发出commit前,会将binlog立即刷到磁盘中。如果这时候已经写入到binlog中,但是还没有提交就已经挂了,那么MySQL重启时,会将通过Redo log、Undo log将这个事务回滚掉,但是binlog已经记入了该事务信息,不能回滚掉。所以我们需要设置innodb_support_xa=1确保MySQL服务层的binlog和MySQL存储引擎层的Redo log、Undo log之间的数据一致性。

    02

    MySQL主从复制数据一致性校验和修复方法及自动化实现

    “MySQL主从复制”技术在互联网行业常见高可用架构中应用非常广泛,例如常见的一主一从复制架构、keepalived+MySQL双主(主从)复制架构、MHA+一主两从复制架构等等都应用了MySQL主从复制技术。但因主从复制是基于binlog的逻辑复制,难免出现复制数据不一致的风险,这个风险不但会引起用户数据访问前后不一致的风险,而且会导致后续复制出现1032、1062错误进而引起复制架构停滞的隐患,为了及时发现并解决这个问题,我们需要定期或不定期地开展主从复制数据一致性的校验和修复工作,那么如何实现这项工作呢?又如何实现这项工作的自动化呢?我们来探讨这些问题。

    02
    领券