《大数据量下，58同城mysql实践》 WOT（World Of Tech）2015，互联网运维与开发者大会将在北京举行，会上58同城将分享《大数据量下，58同城mysql实战》的主题，干货分享抢先看
当一张表的数据达到几千万时，你查询一次所花的时间会变多，如果有联合查询的话，我想有可能会死在那儿了。分表的目的就在于此，减小数据库的负担，缩短查询时间。
做过2B类系统的同学都知道，2B系统最恶心的操作就是什么都喜欢批量，这不，我最近就遇到了一个恶心的需求——50个用户同时每人导入1万条单据，每个单据七八十个字段，请给我优化。
WOT(World Of Tech)2015，互联网运维与开发者大会将在北京举行，会上58同城将分享《大数据量下，58同城mysql实战》的主题，干货分享抢先看。 1)基本概念 2)常见问题及
当然，本篇也是关于性能优化的，那性能优化就应该一把梭子吗？还是要符合一些规范和原则呢？
◆ 冷热分离 本文讲的第一个场景是冷热分离。简单来说，就是将常用的“热”数据和不常使用的“冷”数据分开存储。 本章要考虑的重点是锁的机制、批量处理以及失败重试的数据一致性问题。这部分内容在实际开发中的“陷阱”还是不少的。 首先介绍一下业务场景。 ◆ 1.1 业务场景：几千万数据量的工单表如何快速优化 这次项目优化的是一个邮件客服系统。它是一个SaaS（通过网络提供软件服务）系统，但是大客户只有两三家，最主要的客户是一家大型媒体集团。 这个系统的主要功能是这样的：它会对接客户的邮件服务器，自动收取发到几个
索引是帮助MySQL高效获取数据的数据结构。索引内部存在一个键值和对应数据的物理地址，当数据很多的时候，索引文件会很大，所以一般以文件的形式存储于磁盘中，后缀名为.myi。
之前我们了解了优化器的工作原理，相信你已经可以对单表的 SQL 语句进行索引的设计和调优工作。但除了单表的 SQL 语句，还有两大类相对复杂的 SQL，多表 JOIN 和子查询语句，这就要在多张表上创建索引，难度相对提升不少。
最近有台服务器比较频繁的CPU报警，表现的特征有CPU sys占比偏高，大量慢查询，大量并发线程堆积。后面开发对insert的相关业务限流后，服务器性能恢复正常。
每一个SQL都需要消耗一定的I/O资源，SQL执行的快慢直接决定了资源被占用时间的长短。假设业务要求每秒需要完成100条SQL的执行，而其中10条SQL执行时间过长，从而导致每秒只能完成90条SQL，所有新的SQL将进入排队等待，直接影响业务，然后用户就各种投诉来了。
之前写了一些关于 MySQL 的 InnoDB 存储引擎的文章，里面好几次都提到了页（Pages）这个概念，但是都只是简要的提了一下。例如之前在聊 InnoDB内存结构 时提到过，但当时的重点是内存架构，就没有展开深入。
文章摘要：一个小小的MySQL数据库B-Tree索引可能会带来意想不到的性能优化提升……
查看索引长度是74=(3*24+2),可以算出联合索引中只使用了name前缀索引.
MySQL本身并没有对单表最大记录数进行限制，这个数值取决于你的操作系统对单个文件的限制本身。业界流传是500万行。超过500万行就要考虑分表分库了。
本文想和大家来聊聊Mysql中的执行计划，一条SQL语句经过了查询优化器模块分析后，会得到一个执行计划，通过这个执行计划，我们可以知道该条SQL语句具体采用的多表连接顺序是什么，对于每个表具体采用的访问方法是什么 . . .
单库单表是最常见的数据库设计，例如，有一张用户(user)表放在数据库db中，所有的用户都可以在db库中的user表中查到。
事情的起因是，我们的一个项目经理需要对一个数据库的信息进行查询，SQL 人家都会写的。（语句已经经过处理字段名，和原有的语句不同）语句并不复杂， mysql 5.7.23
目标：查询得到每组的max（或者min等其他聚合函数）值，并且得到这个行的其他字段
一条查询语句在经过MySQL查询优化器的各种基于成本和规则的优化会后生成一个所谓的执行计划，这个执行计划展示了接下来具体执行查询的方式，比如多表连接的顺序是什么，对于每个表采用什么访问方法来具体执行查询等等。设计MySQL的大叔贴心的为我们提供了EXPLAIN语句来帮助我们查看某个查询语句的具体执行计划，本章的内容就是为了帮助大家看懂EXPLAIN语句的各个输出项都是干嘛使的，从而可以有针对性的提升我们查询语句的性能。
顾名思义，cluster（集群）由一台及以上主机节点组成并提供存储及搜索服务，为方便理解可以将其看作为mysql集群； elasticsearch集群名称在配置文件ES_HOME/config/elasticsearch.yml中定义，集群名称默认为elasticsearch，可通过cluster.name: my-application属性定义； 单台节点在集群中的名字可通过node.name: node-1属性定义，默认为自动生成的一个uuid值；
select ...from table where exist (子查询)；
我们知道，所谓表连接就是把各个表中的记录都取出来进行依次匹配，最后把匹配组合的记录一起发送给客户端。比如下面把t1表和t2表连接起来的过程如下图
Python 操作 MySQL 操作流程 image 1.先创建数据库连接，与数据库完成连接，使用语句如下： conn = pymysql.connect() 2.创建游
索引是与效率挂钩的，所以没有索引，可能会存在问题 索引：提高数据库的性能，索引是物美价廉的东西了。不用加内存，不用改程序，不用调sql，只要执行正确的 create index ，查询速度就可能提高成百上千倍。但是天下没有免费的午餐，查询速度的提高是以插入、更新、删除的速度为代价的，这些写操作，增加了大量的IO。所以它的价值，在于提高一个海量数据的检索速度。
这句SQL会使得MySQL在无法利用索引的情况下跳过1000000条记录后，再获取10条记录，其性能可想而知。而在分库分表的情况下（假设分为2个库），为了保证数据的正确性，SQL会改写为：
（实际系统跟这个图是有出入的，不过总体意思是这样。图是使用Excalidraw画的）
innodb 作为最主流使用的 mysql 存储引擎，尤其在新版本的 mysql 中 MyISAM 存储引擎被废除，更加提升了 innodb 如日中天的地位。 那么，作为 mysql 的使用者，如何优化 innodb 使之发挥更强大的性能，就成为了必修课。
SELECT GREATEST(@found := 1, id) AS id ,'uesrs' AS which_tb1
MySQL 从 4.1 版本开始支持子查询，使用子查询可以进行 SELECT 语句的嵌套查询，即一个 SELECT 查询的结果作为另一个 SELECT 语句的条件。子查询可以一次性完成很多逻辑上需要多个步骤才能完成的操作 。
sql优化是一个大家都比较关注的热门话题，无论你在面试，还是工作中，都很有可能会遇到。
眼下用的最多的关系型数据库数MySql莫属了，之前也用过其它各种数据库。最近使用MySql一段时间了，突然好奇心下，想看看MySql到底性能如何？刚好最近手上有一份2000W的数据集，刚好拿过来练练手。
小熊学Java个人网站：https://javaxiaobear.gitee.io/，每周持续更新干货，建议收藏！
在TP5的框架使用过程中，Db类是一定会接触到的，上手不难，但若想随心所欲的用，还是需要了解一番。用了千次，却没看过一次源码，学习源码，起码对TP5这个框架使用更加得心应手，毕竟技术服务于业务，能够写出更简介、更方便、更有效的业务代码，本身就是一件身心愉悦的事儿;
作为在后端圈开车的多年老司机，是不是经常听到过，“mysql 单表最好不要超过 2000w”,“单表超过 2000w 就要考虑数据迁移了”，“你这个表数据都马上要到 2000w 了，难怪查询速度慢”
在技术团队内部进行有效的 SQL 管理并不容易，如何进行数据库的统一管理，和线上 SQL 操作的统一审核，变得尤为重要。Archery，这个开源的 SQL 审核查询平台，或许能为 SQL 审核工作带来不小的效率提升。
除非单表数据未来会一直不断上涨，否则不要一开始就考虑拆分，拆分会带来逻辑、部署、运维的各种复杂度，一般以整型值为主的表在千万级以下，字符串为主的表在五百万以下是没有太大问题的。而事实上很多时候MySQL单表的性能依然有不少优化空间，甚至能正常支撑千万级以上的数据量：
这里显示的是明文密码通过哦MYSQLSHA1加密算法加密后得到的密文密码，是不可逆的，mysql 5.7 的密码保存到 authentication_string 字段中不再使用 password 字段。
这些名言民语就和 “群里只讨论技术，不开车，开车速度不要超过 120 码，否则自动踢群”，只听过，没试过，哈哈。
有关Mysql记录锁、间隙(gap)锁、临键锁(next-key)锁的一些理论知识之前有写过，详细内容可以看这篇文章 一文详解MySQL的锁机制
想必大家也听说过数据库单表建议最大2kw条数据这个说法。如果超过了，性能就会下降得比较厉害。
在MySQL中，我们可以通过EXPLAIN命令获取MySQL如何执行SELECT语句的信息，包括在SELECT语句执行过程中表如何连接和连接的顺序。
提到mysql查询优化，很多人脑海里可能会想到NOT NULL、合理索引、不使用select *、合适的数据类型等等，可是这些优化技巧是怎么来的？
近年来，不少程序员在吹捧MariaDB，抛弃MySQL。本文总结了一些 MariaDB强过MySQL的地方，分享给大家！
MySQL的历史可以追溯到1979年，它的创始人叫作Michael Widenius，他在开发一个报表工具的时候，设计了一套API，后来他的客户要求他的API支持sql语句，他直接借助于mSQL（当时比较牛）的代码，将它集成到自己的存储引擎中。但是他总是感觉不满意，萌生了要自己做一套数据库的想法。一到1996年，MySQL 1.0发布，仅仅过了几个月的时间，1996年10月MySQL 3.11.1当时发布了Solaris的版本，一个月后，linux的版本诞生，从那时候开始，MySQL慢慢的被人所接受。1999年，Michael Widenius成立了MySQL AB公司，MySQL由个人开发转变为团队开发，2000年使用GPL协议开源。2001年，MySQL生命中的大事发生了，那就是存储引擎InnoDB的诞生！直到现在，MySQL可以选择的存储引擎，InnoDB依然是No.1。2008年1月，MySQL AB公司被Sun公司以10亿美金收购，MySQL数据库进入Sun时代。Sun为MySQL的发展提供了绝佳的环境，2008年11月，MySQL 5.1发布，MySQL成为了最受欢迎的小型数据库。在此之前，Oracle在2005年就收购了InnoDB，因此，InnoDB一直以来都只能作为第三方插件供用户选择。2009年4月，Oracle公司以74亿美元收购Sun公司，MySQL也随之进入Oracle时代。2010年12月，MySQL 5.5发布，Oracle终于把InnoDB做成了MySQL默认的存储引擎，MySQL从此进入了辉煌时代。然而，从那之后，Oracle对MySQL的态度渐渐发生了变化，Oracle虽然宣称MySQL依然尊少GPL协议，但却暗地里把开发人员全部换成了Oracle自己人，开源社区再也影响不了MySQL发展的脚步，真正有心做贡献的人也被拒之门外，MySQL随时都有闭源的可能……
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
