当更新一条记录时，分区层先打开并锁住所有的底层表，MySQL先确定需要更新的记录在哪个分区，然后取出数据并更新，再判断更新后的数据应该放在哪个分区，最后对底层表进行写入操作，并对原数据所在的底层表进行删除操作。‘
分区表的类型
根据范围分区（例：2019年销售额，2020年销售额）
根据键值进行分区，来减少InnoDB的互斥量竞争。
使用数学模函数来进行分区，然后将数据轮询放入不同的分区。例如，可以对日期做模7的运算，或者更简单地使用返回周几的函数，如果只想保留最近几天的数据，这样分区很方便。
为了保证大数据量的可扩展性，一般有下面两个策略：全量扫描数据，不要任何索引。索引数据，并分离热点。
什么情况分区会出问题
NULL值会使分区过滤无效（5.5之后语法可解决）
分区列和索引列不匹配（应该避免建立和分区列不匹配的索引，除非查询中还同时包含了可以过滤分区的条件。）
选择分区的成本可能很高（对大多数系统来说，100个左右的分区是没有问题的。键分区和哈希分区，则没有这样的问题。）
查询优化
分区最大的优点就是优化器可以根据分区函数来过滤一些分区。根据粗粒度索引的优势，通过分区过滤通常可以让查询扫描更少的数据（在某些场景下）。
存储过程
通常会希望存储程序越小、越简单越好。希望将更加复杂的处理逻辑交给上层的应用实现，通常这样会使代码更易读、易维护，也会更灵活。这样做也会让你拥有更多的计算资源，潜在的还会让你拥有更多的缓存资源。
触发器
触发器可以让你在执行INSERT、UPDATE 或者DELETE的时候，执行一些特定的操作。可以在MySQL中指定是在SQL语句执行前触发还是在执行后触发。触发器本身没有返回值，不过它们可以读取或者改变触发SQL语句所影响的数据。
需要注意以下几点：
对每一个表的每一个事件，最多只能定义一个触发器。
MySQL只支持“基于行的触发”——也就是说，触发器始终是针对一条记录的，而不是针对整个SQL语句的。如果变更的数据集非常大的话，效率会很低。
下面这些触发器本身的限制：
触发器可以掩盖服务器背后的工作，一个简单的SQL语句背后，因为触发器，可能包含了很多看不见的工作。例如，触发器可能会更新另一个相关表，那么这个触发器会让这条SQL影响的记录数翻一倍。
触发器的问题也很难排查，如果某个性能问题和触发器相关，会很难分析和定位。
触发器可能导致死锁和锁等待。如果触发器失败，那么原来的SQL语句也会失败。如果没有意识到这其中是触发器在搞鬼，那么很难理解服务器抛出的错误代码是什么意思。
事件
事件是MySQL 5.1引入的一种新的存储代码的方式。它类似于Linux的定时任务，不过是完全在MySQL内部实现的。你可以创建事件，指定MySQL在某个时候执行一段SQL代码，或者每隔一个时间间隔执行一段SQL代码。通常，我们会把复杂的SQL都封装到一个存储过程中，这样事件在执行的时候只需要做一个简单的CALL 调用。
在存储程序中保留注释
游标
MySQL在服务器端提供只读的、单向的游标，而且只能在存储过程或者更底层的客户端API中使用。因为MySQL游标中指向的对象都是存储在临时表中而不是实际查询到的数据，所以MySQL游标总是只读的。
