最近有项目需要用到 Mysql8.0 ，但是腾讯云轻量服务器的4G内存，实际可用只有3600多M，在编译安装 Mysql8.0 的时候会 Kill 掉安装进程，导致安装失败。
人生可悲的事情是,你不知道问题如何解决,并且困惑中, 而更可悲的是,你根本就不知道自己不知道, 当然从另一个角度,那也是一种"幸福".
这个标题很吸引眼球实际上内容也应该很好玩. 问题的产生是最近我们在各个数据库进行数据库安装规范的事情,而在规范后,安装的第一台机器,进行压测就惨遭崩溃.
每种数据库都有自己的管理内存的方法，MYSQL 管理内存（仅仅讨论 INNODB 数据库引擎）的方法大部分都关注在 innodb_buffer_pool_size 这个设置。MYSQL 本身内存管理有这么简单吗？
大概就是在几个月之前本人租了一台服务器用来搭建自己的博客(原来的博客是在阿里云香港服务器上面,在十一期间被和谐了),于是租用了1核1G内存的云服务器(三年800多元),可是在使用的过程中发现cpu和内存占用有点异常,查了下发现以下问题:
来源：http://carlosfu.iteye.com/blog/2254572 一、背景 1. AOF: Redis的AOF机制有点类似于MySQL binlog，是Redis的提供的一种
作者 | 张甦， 数据库领域的专家和知名人士、图书《MySQL王者晋级之路》作者，51CTO 专家博主。近10年互联网线上处理及培训经验，专注于 MySQL 数据库，对 MongoDB、Redis 等 NoSQL 数据库以及 Hadoop 生态圈相关技术有深入研究，具备非常丰富的理论与实战经验。
我们知道，直接从物理内存读写数据要比从硬盘读写数据要快的多，因此，我们希望所有数据的读取和写入都在内存完成，而内存是有限的，这样就引出了物理内存与虚拟内存的概念。 物理内存就是系统硬件提供的内存大小，是真正的内存，相对于物理内存，在linux下还有一个虚拟内存的概念，虚拟内存就是为了满足物理内存的不足而提出的策略，它是利用磁盘空间虚拟出的一块逻辑内存，用作虚拟内存的磁盘空间被称为交换空间（Swap Space）。 作为物理内存的扩展，linux会在物理内存不足时，使用交换分区的虚拟内存，更详细的说，就是内核会将暂时不用的内存块信息写到交换空间，这样以来，物理内存得到了释放，这块内存就可以用于其它目的，当需要用到原始的内容时，这些信息会被重新从交换空间读入物理内存。 Linux的内存管理采取的是分页存取机制，为了保证物理内存能得到充分的利用，内核会在适当的时候将物理内存中不经常使用的数据块自动交换到虚拟内存中，而将经常使用的信息保留到物理内存。
Linux中的dev文件目录的全称是device设备的英文，这个目录包含了所有linux中使用的外部设备，但是不包含外部设备的驱动信息。我们先来看看这个目录中包含哪些文件吧：
对于DBA来说Linux比较让人头疼的一个地方是，它不会因为MySQL很重要就避免将分配给MySQL的地址空间映射到swap上。对于频繁进行读写操作的系统而言，数据看似在内存而实际上在磁盘是非常糟糕的，响应时间的增长很可能直接拖垮整个系统。这篇blog主要讲讲我们作为DBA，怎样尽量避免MySQL惨遭swap的毒手。 首先我们要了解点基础的东西，比如说为什么会产生swap。假设我们的物理内存是16G，swap是4G。如果MySQL本身已经占用了12G物理内存，而同时其他程序或者系统模块又需要6G内存，这时候操作系统就可能把MySQL所拥有的一部分地址空间映射到swap上去。 cp一个大文件，或用mysqldump导出一个很大的数据库的时候，文件系统往往会向Linux申请大量的内存作为cache，一不小心就会导致L使用swap。
Linux工具箱。添加设置swap，添加设置SWAP大小，根据你的实际内存进行调整，swap是Linux下的虚拟内存，设置适当的swap可增加服务器稳定性，建议swap容量在真实内存容量的1.5倍左右，若您的服务器内存大于4GB，可设1-2GB的固定值，swap文件默认保存在/www/swap，设置前请确保磁盘空间够用。
作为DBA在日常维护数据库中关键的就是数据库性能问题，对于服务百万级活跃用户，保障性能才是核心，功能全面，产品好，性能扛不住都是扯淡。 这里简单分析导致MySQL慢的可能因素，以及一些处理技巧：
0、使用SSD。资金不足的话，使用RAID设备 【建议使用RAID10，因为RAID5的性能并不太高】
云豆贴心提醒，本文阅读时间7分钟 现在MySQL运行的大部分环境都是在Linux上的，如何在Linux操作系统上根据MySQL进行优化，我们这里给出一些通用简单的策略。这些方法都有助于改进MySQL的性能。 闲话少说，进入正题。 一、CPU 首先从CPU说起。 你仔细检查的话，有些服务器上会有的一个有趣的现象： 你cat /proc/cpuinfo时，会发现CPU的频率竟然跟它标称的频率不一样： 这个是Intel E5-2620的CPU，他是2.00G * 24的CPU，但是，我们发现第5颗C
虚拟机技术可以使得一个只有1g物理内存的机器可以运行总共需要4g内存的任务，主要方法是通过虚拟内存和物理内存映射来实现的，当物理内存不够用的时候，可以通过swap内存(存在于磁盘)和物理内存的交换来释放刚交换的物理内存，使其可以重新分配，当需要使用以前换出的内存时，在进行换入操作。
说个案例：一台Apache服务器，由于其MaxClients参数设置过大，并且恰好又碰到访问量激增，结果内存被耗光，从而引发SWAP，进而负载攀升，最终导致宕机。
pt-osc模仿MySQL内部的改表方式进行改表，但整个改表过程是通过对原始表的拷贝来完成的，即在改表过程中原始表不会被锁定，并不影响对该表的读写操作。
Linux top命令用于实时显示 process 的动态，当我们在命令框中敲入top命令然后回车之后，可以看到如下输出：
官网MySQL有四个版本：GA版、DMR版、RC版、Beta版。一般生产和测试环境使用GA版(常规可用的版本，经过bug修复测试)
MySQL会通过使用内存缓存和缓冲来提高数据库的性能。MySQL里面与内存相关参数的默认值是基于一台使用512M内存的虚拟服务器设定的，因此，当用户使用MySQL时需要根据服务器实际内存的大小，对各个参数的值进行调节。在调整参数之前，需要了解一下MySQL究竟是如何使用内存的。
爱可生南区交付服务部团队 DBA，负责客户 MySQL 的故障处理以及公司数据库集群管理平台 DMP 的日常运维。
上篇文章是关于mysql优化的，那个内容是我大学的时候学习的笔记，最近学习发现一些比较好的内容，在这里分享给大家。 版权源于网上。 工作中使用最多的就是MySQL, 但是mysql的优化也就是通过建索
本文整理了一些MySQL的通用优化方法，做个简单的总结分享，旨在帮助那些没有专职MySQL DBA的企业做好基本的优化工作，至于具体的SQL优化，大部分通过加适当的索引即可达到效果，更复杂的就需要具体分析了。 1、硬件层相关优化 1.1、CPU相关 在服务器的BIOS设置中，可调整下面的几个配置，目的是发挥CPU最大性能，或者避免经典的NUMA问题： 1、选择Performance Per Watt Optimized(DAPC)模式，发挥CPU最大性能，跑DB这种通常需要高运算量的服务就不要考虑节电了；
有时候出现了环境问题，对比是一种很好的方式，如果对比得当，可以避免反复的出现问题，可以根据对比的情况推理出一些可能出现的情况或者问题。 如果对比不当，很可能得出错误的结论。今天就简单举几个例子来说明一下。 MySQL重启的对比 之前出现过一次备机的硬件故障，但是庆幸的是幸亏是备机，备机上意味值有备库，但是实际发现备机上的备库和主库没什么关联，也是让人直冒冷汗，那就搭建备 库吧，结果发现主库没有开启binlog，这种情况下是没有任何办法的，所以在评估之后，发现还有一套环境也是同样的问题，所以就申请了窗口时间来
第一，opt目录下mysql文件夹没有了(解救方法：在opt目录下新建mysql文件夹)
爱可生交付服务部团队北京 DBA，主要负责处理 MySQL 的 troubleshooting 和我司自研数据库自动化管理平台 DMP 的日常运维问题，对数据库及周边技术有浓厚的学习兴趣，喜欢看书，追求技术。
Swap分区在系统的物理内存不够用的时候，把物理内存中的一部分空间释放出来，以供当前运行的程序使用。那些被释放的空间可能来自一些很长时间没有什么操作的程序，这些被释放的空间被临时保存到Swap分区中，等到那些程序要运行时，再从Swap分区中恢复保存的数据到内存中。swap分区是从磁盘空间划分而来，有的是单独使用一个分区，有的是把一个大文件当做swap。
墨墨导读： Mysql的8.0版本出来已经有一段时间了，近期研究下源码调试。整个编译过程越来越复杂了。
对于服务器的一些信息，如果数据量大了之后总是感觉力不从心，需要了解，但是感觉得到的这些信息不够清晰明了。 比如我们得到一台服务器，需要知道最基本的硬件配置，内存情况，磁盘空间情况，哪些磁盘空间问题需要关注，哪些磁盘空间问题可以忽略，swap的使用情况 如何，服务器的操作系统版本，内核版本，上面运行有几个实例，是否启用了ASM，甚至服务器运行了多少天呢，这些信息看起来非常琐碎，也可以通过脚本得 到，但是一直以来感觉都是比较笼统模糊。 今天使用shell脚本进行了简单的改进。 我们来看看基本的效果情况。有了这些
爱可生 DBA 团队成员，主要负责 MySQL 故障处理和公司自动化运维平台维护。对技术执着，为客户负责。
版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/X__Alone/article/details/80926688
对于全栈而言，数据库技能不可或缺，关系型数据库或者nosql，内存型数据库或者偏磁盘存储的数据库，对象存储的数据库或者图数据库……林林总总,但是第一必备技能还应该是MySQL。从LAMP的兴起，到Mariadb的出现，甚至PG的到来，熟练的MySQL技能都是大有用武之地的。
先从swap产生的原理来分析，由于linux内存管理比较复杂，下面以问答的方式列了一些重要的点，方便大家理解：
Nginx Nginx是一款由C语言编写的高性能、轻量级的HTTP和反向代理服务器，同时也是一款IMAP/POP3/SMTP服务器。 nginx.conf：Nginx核心配置文件，linux下默认安装在/etc/nginx/ # Nginx所用用户和组，window下不指定 user www-data; # 工作的子进程数量（通常等于CPU数量或者2倍于CPU） worker_processes auto; # pid存放文件 pid /run/nginx.pid; #
查看Swap分区的大小以及使用情况，一般使用free命令即可，如下所示，Swap大小为512M，目前没有使用Swap分区
MySQL的存储过程在运行过程中的内存管理跟table等运行时候是不一样的，它涉及多层内存管理，在开发时候如果不注意内存管理很容易造成内存泄露。接下来我用以下function的例子来说明，procedure的也是类似的，只是少了return result的过程。
《CDH5部署三部曲》共三篇文章，对CDH5.7.2版本的准备、部署、启动、设置等环节进行实战，内容如下：
1.启动mysql时,一直不成功,查看错误日志 /var/log/mysql/error.log
1.启动MySQL时一直不成功，查看错误日志 /var/log/mysql/error.log
1.查版本号无论做什么都要确认版本号，不同的版本号下会有各种差异。>Select version(数据库
MySQL 对于很多 Linux 从业者而言，是一个非常棘手的问题，多数情况都是因为对数据库出现问题的情况和处理思路不清晰。在进行 MySQL 的优化之前必须要了解的就是 MySQL 的查询过程，很多的查询优化工作实际上就是遵循一些原则让MySQL 的优化器能够按照预想的合理方式运行而已。
k8s，即kubernetes是用于自动部署，扩展和管理容器化应用程序的开源系统。详细的描述就不多说了，官网有更详细的内容。简单来说，k8s，是一个可以操作多台机器调度部署镜像的平台。在k8s中，可以使用集群来组织服务器。集群中会存在一个master节点，该节点是kubernetes的控制节点，负责调度服务器中被称为Node的其他资源。
MySQL调优对于很多程序员而言，都是一个非常棘手的问题，多数情况都是因为对数据库出现问题的情况和处理思路不清晰。在进行MySQL的优化之前必须要了解的就是MySQL的查询过程，很多的查询优化工作实际上就是遵循一些原则让MySQL的优化器能够按照预想的合理方式运行而已。
当在C++代码中，直接引用MySQL头文件时，可能会遇到如下错误： In file included from /usr/include/c++/4.1.0/bits/char_traits.h:46, from /usr/include/c++/4.1.0/string:46, /usr/include/c++/4.1.0/bits/stl_algobase.h:92:28: error: macro "swap" requires 3 arguments, but only 2 given /usr/include/c++/4.1.0/bits/stl_algobase.h:127:26: error: macro "swap" requires 3 arguments, but only 2 given /usr/include/c++/4.1.0/bits/vector.tcc:176:20: error: macro "swap" requires 3 arguments, but only 1 given /usr/include/c++/4.1.0/cctype:70: error: '::isalnum' has not been declared /usr/include/c++/4.1.0/cctype:71: error: '::isalpha' has not been declared /usr/include/c++/4.1.0/cctype:72: error: '::iscntrl' has not been declared /usr/include/c++/4.1.0/cctype:73: error: '::isdigit' has not been declared /usr/include/c++/4.1.0/cctype:74: error: '::isgraph' has not been declared /usr/include/c++/4.1.0/cctype:75: error: '::islower' has not been declared /usr/include/c++/4.1.0/cctype:76: error: '::isprint' has not been declared /usr/include/c++/4.1.0/cctype:77: error: '::ispunct' has not been declared /usr/include/c++/4.1.0/cctype:78: error: '::isspace' has not been declared /usr/include/c++/4.1.0/cctype:79: error: '::isupper' has not been declared /usr/include/c++/4.1.0/cctype:80: error: '::isxdigit' has not been declared /usr/include/c++/4.1.0/cctype:81: error: '::tolower' has not been declared /usr/include/c++/4.1.0/cctype:82: error: '::toupper' has not been declared 解决办法： 尽量对MySQL进行二次包装，让调用者看不到MySQL头文件，如在CPP中包含： #include #include #include 在头文件中只进行引用声明： struct st_mysql; struct st_mysql_res; typedef long num_t; typedef char ** MYSQL_ROW; /** return data as array of strings */ 不要在头文件直接include到MySQL的头文件，而且保证只在一个CPP文件中有对MySQL文件的include，否则你可能遇到很多莫名其妙的编译错误，如果不想到这一点，即使花一天时间也未必能找到错误原因。
innodb_buffer_pool_size = 8M （安装MySQL5.6到小于1G内存服务器上，启动MySQL会失败，报内存分配失败的错误，此时，需要修改my.cnf的内存大小从标准128M设置到8M或者64M）
MySQL对于很多Linux从业者而言，是一个非常棘手的问题，多数情况都是因为对数据库出现问题的情况和处理思路不清晰。在进行MySQL的优化之前必须要了解的就是MySQL的查询过程，很多的查询优化工作实际上就是遵循一些原则让MySQL的优化器能够按照预想的合理方式运行而已。
最近在维护公司线上的服务器，排查了一些问题，所以做一个总结。有一段时间，线上环境变得很卡，客户端请求很多都报超时，因为线上没有良好的apm监控，所以只能通过流量高峰期和日志去排查问题。通过排查，发现数据库的慢查询日志在比之间的暴涨了十倍，然后发现，memcache服务器（8核）负载很高，cpu一直在50%的左右，原因就是memcache服务器内存用完，导致内存的淘汰十分频繁，这样就导致很多请求落到数据库。下面说下主要的排查思路和用到的工具
之所以写这篇文章也是因为前几天出的一个问题，当时业务感觉到卡顿，并且伴随着锁超时的报错。最后通过分析发现是由于磁盘I/Q繁忙导致SQL耗时增加，部分锁竞争激烈的热数据出现了锁等待和锁超时。由此可见，系统的硬件环境对数据库整体性能的影响也是非常大的，MySQL在运行环境中并不是孤立存在的，它的整体性能往往受限于系统最薄弱的环节，今天想和大家分享下，都有哪些系统指标会对数据库的整体性能产生影响，我们又如何进行分析。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
