Mysql

如何保证缓存与数据库双写时的数据一致性？ 在做系统优化时，想到了将数据进行分级存储的思路。因为在系统中会存在一些数据，有些数据的实时性要求不高，比如一些配置信息。基本上配置了很久才会变一次

毫不夸张的说咱们后端工程师，无论在哪家公司，呆在哪个团队，做哪个系统，遇到的第一个让人头疼的问题绝对是数据库性能问题。如果我们有一套成熟的方法论，能让大家快速、准确的去选择出合适的优化方案

作为在后端圈开车的多年老司机，是不是经常听到过，“mysql 单表最好不要超过 2000w”,“单表超过 2000w 就要考虑数据迁移了”，“你这个表数据都马上要到 2000w 了，难怪查询速度慢”

今天给大家分享几个SQL常见的“坏毛病”及优化技巧。 SQL语句的执行顺序： 分页查询是最常用的场景之一，但也通常也是最容易出问题的地方

小伙伴们都知道，MySQL 有四种不同的隔离级别，四种不同的隔离级别会带来三种不同的问题，今天我想再和大家捋一捋这个问题

像MySql等传统的关系型数据库已经不能适用于所有的业务场景，比如电商系统的秒杀场景，APP首页的访问流量高峰场景，很容易造成关系型数据库的瘫痪，随着缓存技术的出现很好的解决了这个问题

我最近几年用MYSQL数据库挺多的，发现了一些非常有用的小玩意，今天拿出来分享到大家，希望对你会有所帮助。

MySQL 主从复制是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL 默认采用异步复制方式，这样从节点不用一直访问主服务器来更新自己的数据

背景 XX实例（一主一从）xxx告警中每天凌晨在报SLA报警，该报警的意思是存在一定的主从延迟（若在此时发生主从切换，需要长时间才可以完成切换，要追延迟来保证主从数据的一致性

最近趁空闲之余，在对MySQL数据库进行插入数据测试，对于如何快速插入数据的操作无从下手，在仅1W数据量的情况下，竟花费接近47s，实在不忍直视！在不断摸索之后，整理出一些较实用的方案

今天来和大家分享MySQL的三个日志文件，可以说 MySQL 的多数特性都是围绕日志文件实现，而其中最重要的有以下三种： redo 日志 undo 日志 binlog 日志 比如更新语句的流程会涉及到

主从数据不一致问题，先介绍下问题产生的背景。 在MySQL 一主多从的架构中，主要有两种，一种是通过客户端直连，一种是通过代理 prxoy 间接连接

MyBatis 令人喜欢的一大特性就是动态 SQL。 在使用 JDBC 的过程中， 根据条件进行 SQL 的拼接是很麻烦且很容易出错的。 MyBatis 动态 SQL 的出现， 解决了这个麻烦

分库分表后设计到的第一个问题就是，如何选择路由key，应该如何对key进行路由。路由key应该在每个表中都存在而且唯一。路由策略应尽量保证数据能均匀进行分布。

对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引

索引结构不会影响单表最大行数，2kw 也只是推荐值，超过了这个值可能会导致 B + 树层级更高，影响查询性能

从对数据操作的粒度来分： 表锁：操作时会锁定整个表 行锁：操作时会锁定当前操作行 从对数据操作的类型分： 读锁（共享锁）：针对同一个份数据，多个读操作可以同时进行而不会互相影响等

这里给大家整理了关于慢SQL优化5个思路和10个经典的案列分析，都是工作中比较常见的案列，希望大家能学以致用，能够更深层次的扩展

分库分表带来的问题 从单一表、单一库切分成多库、多表对于性能的提升是必然的，但是同时也带来了一些问题。

MySQL性能 最大数据量 最大并发数 查询耗时0.5秒 实施原则 数据表设计 数据类型 避免空值 text类型 索引优化 索引分类 优化原则 SQL优化 分批处理 不做列运算 避免Select *