（2）如果想知道MySQL数据库中每个表占用的空间、表记录的行数的话，可以打开MySQL的 information_schema 数据库。在该库中有一个 TABLES 表，这个表主要字段分别是：
在mysql中有一个默认的数据表information_schema，information_schema这张数据表保存了MySQL服务器所有数据库的信息。如数据库名，数据库的表，表栏的数据类型与访问权限等。再简单点，这台MySQL服务器上，到底有哪些数据库、各个数据库有哪些表，每张表的字段类型是什么，各个数据库要什么权限才能访问，等等信息都保存在information_schema表里面，所以请勿删改此表。
在mysql中有一个默认的数据表information_schema，information_schema这张数据表保存了MySQL服务器所有数据库的信息。如数据库名，数据库的表，表栏的数据类型与访问权限等。
max_conecctions：整个MySQL允许的最大连接数 这个参数主要影响的是整个MySQL应用的并发处理能力，当系统中实际需要的连接量大于max_conecctions时，必然会产生连接请求的等待，从而限制了相应的并发量。只要主机性能允许，可将该参数设置得尽可能大一点，500到800左右是一个比较合适的参考值 max_user_connections：每个用户允许的最大连接数 max_user_connections是针对单个用户的连接限制。在一般情况下可能较少使用这个限制，可能只有在一些专门提供M
MySQL是一个非常主流的小型关系型数据库管理系统，除了系统自带的命令行管理工具之外，还有许多其他的图形化管理工具。本系列的上一篇中已经说过了安装步骤，本篇就挑比较常用并且好用的几款图形化软件说说,供大家参考。
对这个问题有兴趣是源于一次开发中遇到要统计人数的需求。类似于“得到”专栏的订阅数。
MySQL是目前互联网公司使用最广的数据库，InnoDB是MySQL使用最广的存储引擎，MyISAM和InnoDB的五项最佳实践，和大家聊聊，尽量多讲“为什么”。
在上一次学习mysql索引和explain后，又观看了一些大佬的视频，补充之前一些遗忘的内容和可能有误的知识点
InnoDB，5项最佳实践，知其所以然？
select ...from table where exist (子查询)；
前几天在网上看了一个帖子，描述的现象是在MySQL中，对in,or,union all的性能的比对，看完之后，我就产生了疑问。 文章的大意是说，使用in,or的查询效率较低，大概查询需要花费11秒，而使用了union all的方式之后，性能提高到了0.02秒。 如果单纯说是MySQL半连接的优化器性能问题，我信，但是看了文中提供的SQL语句，我感觉至少从我使用MySQL 5.7的感觉来看，这个差别会很小，或者说没有差别。 当然有这个想法，自己也得论证不是。我就尝试了两次，文中说数据量
其实是写错了，应该是混沌理论，不过大清早6:00在发这篇的时候，的确是饿了，见谅。
一、缘起 mysql主从复制，读写分离是互联网用的非常多的mysql架构，主从复制最令人诟病的地方就是，在数据量较大并发量较大的场景下，主从延时会比较严重。 为什么mysql主从延时这么大？ 回答：
昨天遇到一个问题, 200万的表里查询9万条数据, 耗时达63秒. 200万数据不算多, 查询9万也还好. 怎么用了这么长的时间呢? 问题是一句非常简单的sql. select * from tk_t
根据上图可以看到QPS：10.73k,实际上真实的并发大量数据到达的时候，我这里最高的QPS是将近15k.而目前单个数据库分片(实例)4CPU8G内存的配置下，最高的性能是7k的QPS。
想要优化 MySQL 查询，就必须要弄清楚 MySQL 在执行查询的时候到底做了哪些事，包含哪些子任务。每一项子任务都可能会导致查询缓慢。MySQL 执行查询的流程如下：
很多开发者可能都没有接触过 MySQL 的架构部署，但是大多数应该都听过集群架构吧。其实 MySQL 集群架构，总结来说一共有好多种，今天我主要总结一下其中常用的 8 种集群架构。
在 mysql 中，使用 delete 命令删除数据后，会发现这张表的数据文件和索引文件却奇怪的没有变小。这是因为 delete 操作并不会真的把数据删除，mysql 实际上只是给删除的数据打了个标记，标记为删除，因此你使用 delete 删除表中的数据，表文件在磁盘上所占空间不会变小，我们这里暂且称之为假删除。
# iptables-A INPUT -s 公司的IP -p tcp -m state --state NEW -m tcp --dport3306 -j ACCEPT
最近迁移一个数据库，500多张表大概600多万条数据，通过navicat导出的数据，再通过source命令导入到mysql8.0
系统从圣诞节那天晚上开始，每天晚上固定十点多到十一点多这个时段，大概瘫痪1h左右，过这时段系统自动恢复。系统瘫痪时的现象就是，网页和App都打不开，请求超时。系统架构：
上篇文章说了当数据量大，并且访问量大的时候，可以把业务和DB分开放在不同的服务器，这时候会出现session问题，可以通过负载均衡器来解决session问题，保证同一个会话每次都发在同一个服务器上，也可以通过单独的服务保存sesion。
全备份的优点是备份保持最新备份，恢复的时候可以花费更少的时间；缺点是如果数据量大，将会花费很多的时间，并对系统造成较长时间的压力。增量备份相反，只需要备份每天的增量日志，备份时间少，对负载压力也小；缺点就是恢复的时候需要全备份加上次备份到故障前的所有日志，恢复时间长一些。
下面只讨论delete场景，首先，delete后面是支持limit关键字的，但仅支持单个参数，也就是[limit row_count]，用于告知服务器在控制命令被返回到客户端前被删除的行的最大值。
小史是一个应届生，虽然学的是电子专业，但是自己业余时间看了很多互联网与编程方面的书，一心想进BAT互联网公司。
最近成功中标一个国内重大酒业集团的公有云项目，因客户自身的IT人员紧张，客户提出要求将应用、数据库的迁移上云作为中标方的服务内容之一。以前，经常接触的政企云项目，一般由服务商配合客户完成迁移方案的拟定，服务商将云资源分配好，由客户自身的厂商完成应用、数据库的迁移。厂商一般进行应用、数据库的重新部署，虽然这种方法较繁杂，但也是最稳妥的一种迁移方式。
尽管学校多年的信息化应用积累了大量的数据，但信息孤岛的壁垒一直没有打破，对这些数据无法进一步的挖掘、分析、加工、整理，不能给学校教育、教学、研发、总务等各方面管理决策提供科学、有效的数据支撑。目前的公司现状：
消息队列（一）MySQL实现消息队列 （原创内容，转载请注明来源，谢谢） 一、概述 消息队列（MessageQueue，通常简称MQ）是一种进程间通信或同一进程的不同线程间的通信方式，是分布式应用间交换信息的一种技术。通过消息队列，应用程序可独立地执行，它们不需要知道彼此的位置、或在继续执行前不需要等待接收程序接收此消息。 消息队列有多种实现方式，可以用关系型数据库（如Mysql）、Nosql（如redis）、现有框架（如rabbitMQ）等。 Mysql处理消息队列的场景：主要是在数据处理量大、耗时久
访问网站突然发现出现了数据库连接失败的界面，未收到服务器告警通知，应该不是访问量大，导致mysql服务崩掉的情况。
相信很多站长都遇到过这种情况，用宝塔面板搭建的网站，有时候MySql数据库会意外自动停止。 比如被不怀好意的人CC造成内存不足等，数据库挂了网站自然就无法访问。 比如配置低的VPS网站访问量大造成服务器负载过高而导致MySql数据库意外停止。 然而我们做为站长又不可能随时看着网站，所以我们就可以利用宝塔的自动任务来让MySql数据库自动启动。 宝塔定时监控MySQL状态，一旦停止则自动重启数据库。 使用方法： 将以下shell脚本加入宝塔任务，并设置10分钟执行一次就可以了。
我们都知道关于全文检索大多公司的选型都是ElasticSearch，为什么是它？可能有的人会回复Es利用倒排索引适用于全文检索，倒排索引怎么存的？倒排索引为什么这么优秀？为什么不是MySql和Redis等（这里只拿代表的关系型数据库MySql和内存型数据库Redis举例子？
本文以视频+文字放送，为你带来腾讯云企业级MySQL-列压缩特性 【需求背景】 当前MySQL有针对行格式级别以及数据库页面级别的压缩，这两种压缩方式在处理一个表，同时有大字段和其它很多小字段，并且针对小字段的读写访问频繁，对大字段的访问不频繁的场景中，它的读写访问都会压缩和解压数据，这造成许多不必要的计算资源浪费。 腾讯云企业级MySQL（CDB）运用列压缩功能来压缩访问不频繁的大字段，同时能够减少整行字段的存储空间，进而提高整体读写访问的效率。 例如一张员工表，前面三个字段分别表示员工 id、年龄以及
就是最近，似乎想明白了有些people的心里世界是多么的有interesting， 平日里那种我过得好不好，与我无关，而与别人过得没我好有关，别人过得不好，显得我过得没有那么糟糕的心里，最终决定自己感
无论什么类型的数据库，数据量大了就需要分页，数据量大了，就要考虑分页的效率等。效率在此不做分析。
MOP 不用多说，指的就是 MySQL、Oracle、PostgreSQL 三种目前最主流的数据库，MOP 系列打算更新 MOP 三种数据库的索引知识、高可用架构及常用 SQL 语句等等，上面已经更新了 MOP 索引相关的文章，今天打算整理一下这三种数据库的常用 SQL 知识，由于文章过长，今天更新中间的一篇之 MySQL 篇。第一篇 Oracle 相关的详见下方链接：MOP 系列|MOP 三种主流数据库常用 SQL(一)。
mysql触发器的缺陷分析 说明 1、使用触发器实现的业务逻辑在出现问题时很难定位。 尤其是涉及多个触发器时，会使后期维护困难。 2、大量使用触发器容易导致代码结构混乱。 增加程序的复杂性。 3、如果需要更改的数据量大，触发器的执行效率会很低。 4、触发器的隐式调用容易被忽视。 很难排查问题。 实例 # 创建表 创建触发器 mysql> CREATE TABLE account (acct_num INT, amount DECIMAL(10,2)); Query OK, 0 rows affected
MySQL的show processlist命令可以显示当时的会话情况，但很多时候都需要查看出问题当时的状态，可惜MySQL没有提供类似history session这样的功能。于是为了方便问题排查，自己写了一个非常简单的抓取MySQL现场session的脚本，生产数据库已经用了很长时间，感觉对trouble shooting还是挺有用的。脚本文件get_processlist.sh内容如下：
MySQL 事务主要用于处理操作量大，复杂度高的数据。比如说，在人员管理系统中，你删除一个人员，你即需要删除人员的基本资料，也要删除和该人员相关的信息，如信箱，文章等等，这样，这些数据库操作语句就构成一个事务！
索引越多，维护索引的成本自然就越高。对于插入、更新、删除等DML操作频繁的手表，如果索引过多，会引入相当高的维护成本，降低DML操作效率，增加相应操作的时间消耗。此外，如果索引过多，MySQL也会犯选择困难病，尽管最终还是会找到可用的索引，但无疑会提高选择的成本。
缘起：有个朋友问我分区表在58的应用，我回答不出来，在我印象中，百度、58都没有听说有分区表相关的应用，业内进行一些技术交流的时候也更多的是自己分库分表，而不是使用分区表。于是去网上查了一下，并询问了58到家的DBA专家，将自己收到的信息沉淀下来，share给大伙。
首先bash -x xbak-all.sh来进行一次全备份，数据量大可能要等一会 再每天夜里2点半进行一次增量备份，脚本将自动执行上一次备份结果来接替备份。
今天在学习MySQL时学到SQL语句时，发现其也是存在存在注释的，我就不是很明白这样的注释到底有啥用？在与度娘一番攀谈交心后得出了答案。在此记录一下。
事务就是一组原子性的 SQL 语句，或者说一个独立的单元。可以理解为一个事务对应的是一组完整的业务（一组SQL），这个事务中的一切操作要么都成功要么都失败，只要有一个操作失败了，那么整个事务操作都将回滚到事务开始前
好麻烦，并且最大缺点就是，如果当前有服务正在使用，这样那个服务不就要崩溃一段时间了吗？如果流量大的时候还会造成严重损失
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
