Tagged: MySQL

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

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

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

[总结]MySQL经验 0

[总结]MySQL经验

如果MySQL磁盘满了,会发生什么?还真被我遇到了! 要进行磁盘碎片化整理。原因是datafree占据的空间太多,看看自己的系统的datafree大不大 show table status from 表名; 100G内存下,MySQL查询200G大表会OOM么?   MySQL中ORDER BY与LIMIT 不要一起用,有大坑 如果order by的列有相同的值时,mysql会随机选取这些行,为了保证每次都返回的顺序一致可以额外增加一个排序字段(比如:id),用两个字段来尽可能减少重复的概率。

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

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

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

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

[汇总]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

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

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

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

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

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

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

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

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