1.MySQL 占用内存涨得特别快，这是因为 MySQL 在执行过程中临时使用的内存是管理在连接对象里面的。

    • 定期断开连接
    • 执行mysql_reset_connection 来重新初始化连接资源。

    2.客户端如果太长时间没动静，连接器就会自动将它断开。

    • 这个时间是由参数 wait_timeout 控制的，默认值是 8 小时。

    3.查询缓存往往弊大于利。

    • 查询缓存的失效非常频繁，只要有对一个表的更新，这个表上所有的查询缓存都会被清空。
    • 一个系统配置表，那这张表上的查询才适合使用查询缓存。
    • 需要注意的是，MySQL 8.0 版本直接将查询缓存的整块功能删掉了，也就是说 8.0 开始彻底没有这个功能了。

    4.更新语句redo-log（重做日志），bin-log（归档日志）

    • redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。
    • redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog 是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 ”。
    • redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

    小结：

    1. redo log 用于保证 crash-safe 能力。innodb_flush_log_at_trx_commit 这个参数设置成 1 的时候，表示每次事务的 redo log 都直接持久化到磁盘。参数设置成 1，这样可以保证 MySQL 异常重启之后数据不丢失。
    2. sync_binlog 这个参数设置成 1 的时候，表示每次事务的 binlog 都持久化到磁盘。这样可以保证 MySQL 异常重启之后 binlog 不丢失。

    5.误删表，需要找回数据

    • 首先，找到最近的一次全量备份，如果你运气好，可能就是昨天晚上的一个备份，从这个备份恢复到临时库；
    • 然后，从备份的时间点开始，将备份的 binlog 依次取出来，重放到中午误删表之前的那个时刻。

    6.如何避免长事务对业务的影响？

    应用开发端：

    • set autocommit=1
    • 确认是否有不必要的只读事务
    • 通过 SET MAX_EXECUTION_TIME 命令，来控制每个语句执行的最长时间

    数据库端：

    • 监控 information_schema.Innodb_trx 表，设置长事务阈值，超过就报警 / 或者 kill；
    • Percona 的 pt-kill 这个工具不错，推荐使用；
    • 在业务功能测试阶段要求输出所有的 general_log，分析日志行为提前发现问题；
    • 如果使用的是 MySQL 5.6 或者更新版本，把 innodb_undo_tablespaces 设置成 2（或更大的值）。如果真的出现大事务导致回滚段过大，这样设置后清理起来更方便。

    7.锁

    • 全局锁的典型使用场景是，做全库逻辑备份

    8.
    image.png
    根据username，password建立联合索引