案例背景 案例分析 MySQL 主从结构 案例解答 总结 案例背景 假设你公司面临双 11 大促，投入了大量营销费用用于平台推广，这带来了巨大的流量，如果你是订单系统的技术负责人，要怎么应对突如其来的读写流量呢? 这是一个很典型的应用场景，我想很多研发工程师会回答：通过 Redis 作为 MySQL 的缓存，然后当用户查看“订单中心”时，通过查询订单缓存，帮助 MySQL 抗住大部分的查询请求。

索引，可能让好很多人望而生畏，毕竟每次面试时候 MySQL 的索引一定是必问内容，哪怕先撇开面试，就在平常的开发中，对于 SQL 的优化也而是重中之重。 可以毫不夸张的说，系统中 SQL 的好坏，是能直接决定你系统的快慢的。但是在优化之前大家是否想过一个问题？那就是：我们优化的原则是什么？优化SQL的理论基础是什么？ 虽然说实践出真知，但是我更相信理论是支撑实践的基础，因为我们不可能毫无目的的去盲目的实践，因为这样往往事倍功半。 所以说

图片来自 Pexels MySQL 最多使用一个条件涉及的索引来过滤，然后剩余的条件只能在遍历行过程中进行内存过滤。 上述这种处理复杂条件查询的方式因为只能通过一个索引进行过滤，所以需要进行大量的 I/O 操作来读取行数据，并消耗 CPU 进行内存过滤，导致查询性能的下降。 而 ElasticSearch 因其特性，十分适合进行复杂条件查询，是业界主流的复杂条件查询场景解决方案，广泛应用于订单和日志查询等场景。 下面我们就一起来看一下

1.创建索引方法 创建索引可以在建表时指定，也可以建表后使用 alter table 或 create index 语句创建索引。下面展示下几种常见的创建索引场景。 #建表时指定索引 CREATETABLE`t_index`( `increment_id`int(11)NOTNULLAUTO_INCREMENTCOMMENT'自增主键', `col1`int(11)NOTNULL, `col2`varchar(20)NOTNULL, `

温故而知新 知识这个东西，看来真的要温故而知新，一直不用，都要忘记了。 业务很简单：需要批量插入一些数据，数据来源可能是其他数据库的表，也可能是一个外部excel的导入。 那么问题来了，是不是每次插入之前都要查一遍，看看重不重复，在代码里筛选一下数据，重复的就过滤掉呢？ 向大数据数据库中插入值时，还要判断插入是否重复，然后插入。如何提高效率？ 看来这个问题不止我一个人苦恼过。 解决的办法有很多种，不同的场景解决方案也不一样，数据量很小的

相信大家在平时工作中都有过 SQL 优化经历，那么在优化前就必须找到慢 SQL 方可进行分析。这篇文章就介绍下如何定位到慢查询。 慢查询日志是 MySQL 内置的一项功能，可以记录执行超过指定时间的 SQL 语句。 以下是慢查询的相关参数，大家感兴趣的可以看下： 参数 含义 log_output 日志输出位置，默认为 FILE，即保存为文件，若设置为 TABLE，则将日志记录到 mysql.show_log 表中，支持设置

背景 上个月跟朋友一起做了个微信小程序，趁着5.20节日的热度，两个礼拜内迅速积累了一百多万用户，我们在小程序页面增加了收集formid的埋点，用于给微信用户发送模板消息通知。 这个小程序一开始的后端逻辑是用douchat框架写的，使用框架自带的dc_mp_fans表存储微信端授权登录的用户信息，使用dc_mp_tempmsg表存储formid。截止到目前，收集到的数据超过380万，很大一部分formid都已经成功使用给用户发送过模板通知

无论什么时候，只要存在多个连接在同一时刻修改数据，都会涉及到并发控制的问题。MySQL实现了两个层面的并发控制：服务层和引擎层。 锁分类 按照使用场景分类 共享锁：共享锁(shared lock)也称为读锁(read lock)。共享锁是共享的，或者说是相互不阻塞的。多个连接在同一时刻可以同时读取同一个资源，而不相互干扰。 排他锁：排他锁(exclusive lock)也称为写锁(write lock)。写锁是排他的，也就是一个写锁会