Mobabel

Just One Pure ITer

Tagged: MySQL

[转]日订单量达到100万单后，我们做了订单中心重构 0

MySQL Theory & Solution

[转]日订单量达到100万单后，我们做了订单中心重构

1. 背景 几年前我曾经服务过的一家电商公司，随着业务增长我们每天的订单量很快从30万单增长到了100万单，订单总量也突破了一亿。当时用的Mysql数据库。根据监控，我们的每秒最高订单量已经达到了2000笔（不包括秒杀，秒杀TPS已经上万了。秒杀我们有一套专门的解决方案，详见《秒杀系统设计～亿级用户》）。不过，直到此时，订单系统还是单库单表，幸好当时数据库服务器配置不错，我们的系统才能撑住这么大的压力。 业务量还在快速增长，再不重构系统早晚出大事，我们花了一天时间快速制定了重构方案。 重构？说这么高大上，不就是分库分表吗？的确，就是分库分表。不过除了分库分表，还包括管理端的解决方案，比如运营，客服和商务需要从多维度查询订单数据，分库分表后，怎么满足大家的需求？分库分表后，上线方案和数据不停机迁移方案都需要慎重考虑。为了保证系统稳定，还需要考虑相应的降级方案。

[总结]MySQL经验 0

MySQL Theory & Solution

[总结]MySQL经验

SQL连接图解演示-共七页   数据库底层数据结构与数据库索引类型 跳表，哈希索引，SSTable，LSM树，B树，倒排索引，R树，后缀树。   如果MySQL磁盘满了，会发生什么？还真被我遇到了！ 要进行磁盘碎片化整理。原因是datafree占据的空间太多，看看自己的系统的datafree大不大 show table status from 表名; 100G内存下，MySQL查询200G大表会OOM么？   MySQL中ORDER BY与LIMIT 不要一起用，有大坑 如果order by的列有相同的值时，mysql会随机选取这些行，为了保证每次都返回的顺序一致可以额外增加一个排序字段（比如：id），用两个字段来尽可能减少重复的概率。

[总结]MySQL主从读写分离经验 0

MySQL Master/Slave, R/W Seperation

[总结]MySQL主从读写分离经验

数据库读写分离的这些坑，让我一脸懵逼！ 「由于数据库同步存在延时，这就导致数据同步的这段时间，主从数据将会不一致，从库无法查询到最新的数据。」 最优解：缓存路由大法

[汇总]MySQL优化经验和理论 0

Performance Diagnosing

[汇总]MySQL优化经验和理论

MySQL每秒50w+的写入，如何实现？ innodb，它是我们建表的首选存储引擎   为什么 MySQL 索引要使用 B+树而不是其它树形结构？比如 B 树？ 那么可以算出一棵高度为2的B+树，能存放1170*16=18720条这样的数据记录。根据同样的原理我们可以算出一个高度为3的B+树可以存放：1170*1170*16=21902400条这样的记录。 一款SQL自动检查神器，再也不用担心SQL出错了！Yearning 两类非常隐蔽的全表扫描，不能命中索引 第一类：“列类型”与“where值类型”不符，不能命中索引，会导致全表扫描(full table scan)。 第二类：相join的两个表的字符编码不同，不能命中索引，会导致笛卡尔积的循环计算（nested loop）。

[转]自增主键用完了怎么办？ 0

Distributed Global ID Generator

[转]自增主键用完了怎么办？

1. 引言 在面试中，大家应该经历过如下场景 面试官:”用过mysql吧，你们是用自增主键还是UUID？” 你:”用的是自增主键” 面试官:”为什么是自增主键？” 你:”因为采用自增主键，数据在物理结构上是顺序存储，性能最好，blabla…” 面试官:”那自增主键达到最大值了，用完了怎么办？” 你:”what，没复习啊！！”    (然后，你就可以回去等通知了！) 这个问题是一个粉丝给我提的，我觉得挺有意(KENG)思(B)! 于是，今天我们就来谈一谈，这个自增主键用完了该怎么办！

[转]业务库负载翻了百倍，我做了什么来拯救MySQL架构？ 0

MySQL Master/Slave, R/W Seperation

[转]业务库负载翻了百倍，我做了什么来拯救MySQL架构？

最近有一个业务库的负载比往常高了很多，最直观的印象就是原来的负载最高是100%，现在不是翻了几倍或者指数级增长，而是突然翻了100倍，导致业务后端的数据写入剧增，产生了严重的性能阻塞。 1. 一、引入读写分离，优化初见成效 这类问题引起了我的兴趣和好奇心，经过和业务方沟通了解，这个业务是记录回执数据的，简单来说就好比你发送了一条微博，想看看有多少人已读，有多少人留言等。所以这类场景不存在事务，会有数据的密集型写入，会有明确的统计需求。

[转]百亿大表任意维度查询，如何做到毫秒级返回 0

MySQL Theory & Solution

[转]百亿大表任意维度查询，如何做到毫秒级返回

随着闲鱼业务的发展，用户规模达到数亿级，用户维度的数据指标，达到上百个之多。 如何从亿级别的数据中，快速筛选出符合期望的用户人群，进行精细化人群运营，是技术需要解决的问题。业界的很多方案常常需要分钟级甚至小时级才能生成查询结果。本文提供了一种解决大数据场景下的高效数据筛选、统计和分析方法，从亿级别数据中，任意组合查询条件，筛选需要的数据，做到毫秒级返回。