本文目录一览：
- 1、怎么在linux中使用mysql
- 2、linux 下怎么优化mysql占用内存
- 3、linux apache 性能调优 8G 8核 的服务器
- 4、linux 下怎么优化mysql占用内存？
- 5、优化MYSQL数据库的方法
怎么在linux中使用mysql
这个要看你的linux的发行版。常见的Linux的发行版有Ubuntu、CentOS等。那么不同的发行版，整个的安装、管理、使用都会有一些不同，但是具体差距不大，不过这个要是用文字去说，那就不是三两句话能说清楚的了。建议你去 91课 去看一下MySQL的视频课程，每节课也就10分钟以内，短时间就能了解在不同的linux发行版当中如何使用MySQL。百度知道是不允许发网址链接，所以你还是自己搜索一下吧
linux 下怎么优化mysql占用内存
Linux 进程通过 C 标准库中的内存分配函数 malloc 向系统申请内存，但是到真正与内核交互之间，其实还隔了一层，即内存分配管理器(memory allocator)。常见的内存分配器包括：ptmalloc(Glibc)、tcmalloc(Google)、jemalloc(FreeBSD)。MySQL 默认使用的是 glibc 的 ptmalloc 作为内存分配器。
内存分配器采用的是内存池的管理方式，处在用户程序层和内核层之间，它响应用户的分配请求，向操作系统申请内存，然后将其返回给用户程序。
为了保持高效的分配，分配器通常会预先向操作系统申请一块内存，当用户程序申请和释放内存的时候，分配器会将这些内存管理起来，并通过一些算法策略来判断是否将其返回给操作系统。这样做的最大好处就是可以避免用户程序频繁的调用系统来进行内存分配，使用户程序在内存使用上更加高效快捷。
关于 ptmalloc 的内存分配原理，个人也不是非常了解，这里就不班门弄斧了，有兴趣的同学可以去看下华庭的《glibc 内存管理 ptmalloc 源代码分析》【文末链接】。
关于如何选择这三种内存分配器，网上资料大多都是推荐摒弃 glibc 原生的 ptmalloc，而改用 jemalloc 或者 tcmalloc 作为默认分配器。因为 ptmalloc 的主要问题其实是内存浪费、内存碎片、以及加锁导致的性能问题，而 jemalloc 与 tcmalloc 对于内存碎片、多线程处理优化的更好。
目前 jemalloc 应用于 Firefox、FaceBook 等，并且是 MariaDB、Redis、Tengine 默认推荐的内存分配器，而 tcmalloc 则应用于 WebKit、Chrome 等。
linux apache 性能调优 8G 8核 的服务器
[检测工具]
为了得到完整的调试结果，建议你采用 ApacheBench 或者 httperf之类的软件。如果你对非 LAMP 架构的服务器测试有兴趣的话，建议你采用微软的免费软件： Web Application Stress Tool（需要 NT 或者 2000）。 （其它服务器测试工具）
检测 Apache ，采用 top d 1 显示所有进程的 CPU 和内存情况。另外，还采用 apachectl status 命令
[硬件优化]
1、升级硬件的一般规则：对于 PHP 脚本而言，主要的瓶颈是 CPU ，对于静态页面而言，瓶颈是内存和网络。一台 400 Mhz 的普通奔腾机器所下载的静态页面就能让 T3 专线（45Mbps）饱和。
2、采用 hdparm 来优化磁盘，一般能提升 IDE 磁盘读写性能 200%，但是对 SCSI 硬盘也有效果。（不同类型的硬盘对比）
[策略优化]
3、Apache 处理 PHP 脚本的速度要比静态页面慢 2-10 倍，因此尽量采用多的静态页面，少的脚本。
4、PHP 脚本如果不做缓冲，每次调用都需要编译，因此，安装一个 PHP 缓冲产品能提升 25-100% 的性能。
5、如果你采用了 Linux 系统，建议升级内核到 2.4，因为静态页面由内核服务。
6、另外一项缓冲技术是把不常修改的 PHP 页面采用 HTML 缓冲输出。
7、不要在 Web 服务器上运行 X-Windows ，关掉没有必要运行的进程。
8、如果能够用文本就不要用图像，尽量减小图片的尺寸。
9、分散负载，把数据库服务器放到另外的机器上去。采用另外低端的机器服务图片和 HTML 页面，如果所有的静态页面在另外一台服务器上处理，可以设置 httpd.conf 中的 KeepAlives 为 off ，来减少断开连接的时间。
10、以上所有的方法都是针对单机而言的，如果你觉得系统还是不够快，可以采用集群，负载均衡，缓冲技术。采用 Squid 作为缓冲，配置 Squid 的方法。
[编译优化]
11、把基于文件的会话切换到基于共享内存的会话。编译 PHP 时采用 --with-mm 选项，在 php.ini 中设置 set session.save_handler=mm 。这个简单的修改能让会话管理时间缩短一半。
12、采用最新版本的 Apache ，并把 PHP 编译其中，或者采用 DSO 模式，不要采用 CGI 方式。
13、编译 PHP 时，建议采用如下的参数：
--enable-inline-optimization --disable-debug
[配置优化]
14、修改 httpd.conf ：
# 关闭 DNS lookups，PHP 脚本只拿 IP 地址
HostnameLookups off
15、如果网络拥挤，CPU 资源不够用，采用 PHP 的 HTML 压缩功能：
output_handler = ob_gzhandler
PHP 4.0.4 的用户请不要使用，因为存在内存泄漏问题。
16、修改 httpd.conf 中的 SendBufferSize 为你最大的页面文件的大小。加大内核的 TCP/IP 写缓冲大小。
17、采用数据库的持久连接时，不要把 MaxRequestsPerChild 设置得太大。
[第三方软件优化]
18、如果喜欢从修改 Apache 源码入手，可以安装 lingerd。在页面产生和发送后，每个 Apache 进程都会浪费一段时光在客户连接上，Lingerd 能接管这项工作，让 Apache 迅速服务下一个客户请求。
19、如果你足够勇敢的话，还可以采用 Silicon Graphics 的 Accelerated Apache 补丁。这个工程能使 Apache 1.3 快 10 倍，使 Apache 2.0 快 4 倍。
安装一个 PHP 缓冲产品能提升 25-100% 的性能。
[Linux系统优化]
1.清理服务器磁盘碎片：
不论Linux文件系统采用什么文件格式（ext3、JFS、XFS、ReiserFS ）、何种类型的硬盘(IDE 、SCSI)，随着时间的推移文件系统都会趋向于碎片化。ext3、JFS等高级文件系统可以减少文件系统的碎片化，但是并没有消除。在繁忙的数据库服务器中，随着时间的过去，文件碎片化将降低硬盘性能，硬盘性能从硬盘读出或写入数据时才能注意到。时间长了会发现每个磁盘上确实积累了非常多的垃圾文件，释放磁盘空间可以帮助系统更好地工作。Linux最好的整理磁盘碎片的方法是做一个完全的备份，重新格式化分区，然后从备份恢复文件。但是对于7×24小时工作关键任务服务器来说是比较困难的。Kleandisk是一个高效的磁盘清理工具，它能把磁盘上的文件分成不同的"组",比如把所有的"core"文件归成一组（Group），这样要删除所有core文件时只要删除这个组就行了。core文件是当软件运行出错时产生的文件，它对于软件开发人员比较有用，对于其他用户（比如电子邮件服务器）却没有任何意义。因此，如果没有软件开发的需要，见到core文件就可以将其删除。
2、开启硬盘DMA
现在使用的IDE硬盘基本支持DMA66/100/133（直接内存读取）但是Linux发行版本安装后一般没有打开，可以 /etc/rc.d/rc.local 最後面加上一行： /sbin/hdparm -d1 –x66 -c3 -m16 /dev/hda 这样以后每次开机，硬盘的 DMA 就会开启，不必每次手动设定。添加前后你可以使用命令：hdparm -Tt /dev/hda 来测试对比一下。
3、调整缓冲区刷新参数
Linux内核中，包含了一些对于系统运行态的可设置参数。缓冲刷新的参数可以通过调整 /proc/sys/vm/bdflush文件来完成，这个文件的格式是这样的：
每一栏是一个参数，其中最重要的是前面几个参数。第一个数字是在"dirty"缓冲区达到多少的时候强制唤醒bdflush进程刷新硬盘，第二个数字是每次让bdflush进程刷新多少个dirty块。所谓dirty块是必须写到磁盘中的缓存块。接下来的参数是每次允许bd flush将多少个内存块排入空闲的缓冲块列表。 以上值为RHEL 4.0中的缺省值。可以使用两种方法修改：
（1）使用命令
# echo "100 128 128 512 5000 3000 60 0 0"/proc/sys/vm/bdflush
并将这条命令加到/etc/rc.d/rc.local文件中去。
（2）在/etc/sysctl.conf 文件中加入如下行:
以上的设置加大了缓冲区大小，降低了bdflush被启动的频度，VFS的缓冲刷新机制是Linux文件系统高效的原因之一。
4、优化输入输出
I/O程序对Linux系统性能也是相当重要的，网络硬件I/O对服务器尤其重要。现在大多数Linux服务器使用10/100 Mb以太网。如果有较重的网络负载，则可以考虑千兆以太网卡。如果没有能力购买千兆网卡的话：可以使用多块网卡虚拟成为一块网卡，具有相同的IP地址。这项技术，在Linux中，这种技术称为Bonding。Bonding在Linux2.4以上内核中已经包含了，只需要在编译的时候把网络设备选项中的 Bonding driver support选中见图1。当然利用Bonding技术配置双网卡绑定的前提条件是两块网卡芯片组型号相同，并且都具备独立的BIOS芯片。
然后，重新编译核心，重新起动计算机，执行如下命令：
现在两块网卡已经象一块一样工作了。这样可以提高集群节点间的数据传输.bonding对于服务器来是个比较好的选择,在没有千兆网卡时,用两块100兆网卡作bonding,可大大提高服务器到交换机之间的带宽.但是需要在交换机上设置连接bonding网卡的两个子口映射为同一个虚拟接口。编辑 /etc/modules.conf文件，加入如下内容，以使系统在启动时加载Bonding模块。
“mode”的值表示工作模式，共有0、1、2和3四种模式，这里设定为0。Bonding工作在负载均衡（Load Balancing (round-robin)）方式下，即两块网卡同时工作，这时理论上Bonding能提供两倍的带宽。Bonding运行在网卡的混杂（Promisc）模式下，而且它将两块网卡的MAC地址修改为一样的。混杂模式就是网卡不再只接收目的硬件地址是自身MAC地址的数据帧，而是可以接收网络上所有的帧。
5、减少虚拟终端机的数量。
Linux安装后系统默认是6个虚拟终端机，也就是 CTRL+ALT F1～F6 那六个，作为服务器使用可以关掉其中四个，只留下 CTRL+ALT F1～F2，大约省下 4 Mbytes 的内存，但是这样一来，X-Window 会从原来的 CTRL+ALT F7 变成 CTRL+ALT F3 。 修改 /etc/inittab 中，将 mingetty 3 ～6 全部加上 # 字号 。
6. 关闭一些不用的服务
Linux服务器在启动时需要启动很多系统服务，它们向本地和网络用户提供了Linux的系统功能接口，直接面向应用程序和用户。提供这些服务的程序是由运行在后台的守护进程（daemons）来执行的。守护进程是生存期长的一种进程。它们独立于控制终端并且周期性的执行某种任务或等待处理某些发生的事件。他们常常在系统引导装入时启动，在系统关闭时终止。linux系统有很多守护进程，大多数服务器都是用守护进程实现的。如Web服务http等。同时，守护进程完成许多系统任务，比如，作业规划进程crond、打印进程lqd等。
linux 下怎么优化mysql占用内存？
Linux 进程通过 C 标准库中的内存分配函数 malloc 向系统申请内存，但是到真正与内核交互之间，其实还隔了一层，即内存分配管理器(memory allocator)。常见的内存分配器包括：ptmalloc(Glibc)、tcmalloc(Google)、jemalloc(FreeBSD)。MySQL 默认使用的是 glibc 的 ptmalloc 作为内存分配器。
内存分配器采用的是内存池的管理方式，处在用户程序层和内核层之间，它响应用户的分配请求，向操作系统申请内存，然后将其返回给用户程序。
为了保持高效的分配，分配器通常会预先向操作系统申请一块内存，当用户程序申请和释放内存的时候，分配器会将这些内存管理起来，并通过一些算法策略来判断是否将其返回给操作系统。这样做的最大好处就是可以避免用户程序频繁的调用系统来进行内存分配，使用户程序在内存使用上更加高效快捷。
关于 ptmalloc 的内存分配原理，个人也不是非常了解，这里就不班门弄斧了，有兴趣的同学可以去看下华庭的《glibc 内存管理 ptmalloc 源代码分析》【文末链接】。
关于如何选择这三种内存分配器，网上资料大多都是推荐摒弃 glibc 原生的 ptmalloc，而改用 jemalloc 或者 tcmalloc 作为默认分配器。因为 ptmalloc 的主要问题其实是内存浪费、内存碎片、以及加锁导致的性能问题，而 jemalloc 与 tcmalloc 对于内存碎片、多线程处理优化的更好。
目前 jemalloc 应用于 Firefox、FaceBook 等，并且是 MariaDB、Redis、Tengine 默认推荐的内存分配器，而 tcmalloc 则应用于 WebKit、Chrome 等。
优化MYSQL数据库的方法
在开始演示之前，我们先介绍下两个概念。
概念一，数据的可选择性基数，也就是常说的cardinality值。
查询优化器在生成各种执行计划之前，得先从统计信息中取得相关数据，这样才能估算每步操作所涉及到的记录数，而这个相关数据就是cardinality。简单来说，就是每个值在每个字段中的唯一值分布状态。
比如表t1有100行记录，其中一列为f1。f1中唯一值的个数可以是100个，也可以是1个，当然也可以是1到100之间的任何一个数字。这里唯一值越的多少，就是这个列的可选择基数。
那看到这里我们就明白了，为什么要在基数高的字段上建立索引，而基数低的的字段建立索引反而没有全表扫描来的快。当然这个只是一方面，至于更深入的探讨就不在我这篇探讨的范围了。
概念二，关于HINT的使用。
这里我来说下HINT是什么，在什么时候用。
HINT简单来说就是在某些特定的场景下人工协助MySQL优化器的工作，使她生成最优的执行计划。一般来说，优化器的执行计划都是最优化的，不过在某些特定场景下，执行计划可能不是最优化。
比如：表t1经过大量的频繁更新操作，（UPDATE,DELETE,INSERT），cardinality已经很不准确了，这时候刚好执行了一条SQL，那么有可能这条SQL的执行计划就不是最优的。为什么说有可能呢？
来看下具体演示
譬如，以下两条SQL，
A：
select * from t1 where f1 = 20;
B：
select * from t1 where f1 = 30;
如果f1的值刚好频繁更新的值为30，并且没有达到MySQL自动更新cardinality值的临界值或者说用户设置了手动更新又或者用户减少了sample page等等，那么对这两条语句来说，可能不准确的就是B了。
这里顺带说下，MySQL提供了自动更新和手动更新表cardinality值的方法，因篇幅有限，需要的可以查阅手册。
那回到正题上，MySQL 8.0 带来了几个HINT，我今天就举个index_merge的例子。
示例表结构：
mysql desc t1;+------------+--------------+------+-----+---------+----------------+| Field | Type | Null | Key | Default | Extra |+------------+--------------+------+-----+---------+----------------+| id | int(11) | NO | PRI | NULL | auto_increment || rank1 | int(11) | YES | MUL | NULL | || rank2 | int(11) | YES | MUL | NULL | || log_time | datetime | YES | MUL | NULL | || prefix_uid | varchar(100) | YES | | NULL | || desc1 | text | YES | | NULL | || rank3 | int(11) | YES | MUL | NULL | |+------------+--------------+------+-----+---------+----------------+7 rows in set (0.00 sec)
表记录数：
mysql select count(*) from t1;+----------+| count(*) |+----------+| 32768 |+----------+1 row in set (0.01 sec)
这里我们两条经典的SQL：
SQL C：
select * from t1 where rank1 = 1 or rank2 = 2 or rank3 = 2;
SQL D：
select * from t1 where rank1 =100 and rank2 =100 and rank3 =100;
表t1实际上在rank1,rank2,rank3三列上分别有一个二级索引。
那我们来看SQL C的查询计划。
显然，没有用到任何索引，扫描的行数为32034，cost为3243.65。
mysql explain format=json select * from t1 where rank1 =1 or rank2 = 2 or rank3 = 2\G*************************** 1. row ***************************EXPLAIN: { "query_block": { "select_id": 1, "cost_info": { "query_cost": "3243.65" }, "table": { "table_name": "t1", "access_type": "ALL", "possible_keys": [ "idx_rank1", "idx_rank2", "idx_rank3" ], "rows_examined_per_scan": 32034, "rows_produced_per_join": 115, "filtered": "0.36", "cost_info": { "read_cost": "3232.07", "eval_cost": "11.58", "prefix_cost": "3243.65", "data_read_per_join": "49K" }, "used_columns": [ "id", "rank1", "rank2", "log_time", "prefix_uid", "desc1", "rank3" ], "attached_condition": "((`ytt`.`t1`.`rank1` = 1) or (`ytt`.`t1`.`rank2` = 2) or (`ytt`.`t1`.`rank3` = 2))" } }}1 row in set, 1 warning (0.00 sec)
我们加上hint给相同的查询，再次看看查询计划。
这个时候用到了index_merge,union了三个列。扫描的行数为1103，cost为441.09，明显比之前的快了好几倍。
mysql explain format=json select /*+ index_merge(t1) */ * from t1 where rank1 =1 or rank2 = 2 or rank3 = 2\G*************************** 1. row ***************************EXPLAIN: { "query_block": { "select_id": 1, "cost_info": { "query_cost": "441.09" }, "table": { "table_name": "t1", "access_type": "index_merge", "possible_keys": [ "idx_rank1", "idx_rank2", "idx_rank3" ], "key": "union(idx_rank1,idx_rank2,idx_rank3)", "key_length": "5,5,5", "rows_examined_per_scan": 1103, "rows_produced_per_join": 1103, "filtered": "100.00", "cost_info": { "read_cost": "330.79", "eval_cost": "110.30", "prefix_cost": "441.09", "data_read_per_join": "473K" }, "used_columns": [ "id", "rank1", "rank2", "log_time", "prefix_uid", "desc1", "rank3" ], "attached_condition": "((`ytt`.`t1`.`rank1` = 1) or (`ytt`.`t1`.`rank2` = 2) or (`ytt`.`t1`.`rank3` = 2))" } }}1 row in set, 1 warning (0.00 sec)
我们再看下SQL D的计划：
不加HINT，
mysql explain format=json select * from t1 where rank1 =100 and rank2 =100 and rank3 =100\G*************************** 1. row ***************************EXPLAIN: { "query_block": { "select_id": 1, "cost_info": { "query_cost": "534.34" }, "table": { "table_name": "t1", "access_type": "ref", "possible_keys": [ "idx_rank1", "idx_rank2", "idx_rank3" ], "key": "idx_rank1", "used_key_parts": [ "rank1" ], "key_length": "5", "ref": [ "const" ], "rows_examined_per_scan": 555, "rows_produced_per_join": 0, "filtered": "0.07", "cost_info": { "read_cost": "478.84", "eval_cost": "0.04", "prefix_cost": "534.34", "data_read_per_join": "176" }, "used_columns": [ "id", "rank1", "rank2", "log_time", "prefix_uid", "desc1", "rank3" ], "attached_condition": "((`ytt`.`t1`.`rank3` = 100) and (`ytt`.`t1`.`rank2` = 100))" } }}1 row in set, 1 warning (0.00 sec)
加了HINT，
mysql explain format=json select /*+ index_merge(t1)*/ * from t1 where rank1 =100 and rank2 =100 and rank3 =100\G*************************** 1. row ***************************EXPLAIN: { "query_block": { "select_id": 1, "cost_info": { "query_cost": "5.23" }, "table": { "table_name": "t1", "access_type": "index_merge", "possible_keys": [ "idx_rank1", "idx_rank2", "idx_rank3" ], "key": "intersect(idx_rank1,idx_rank2,idx_rank3)", "key_length": "5,5,5", "rows_examined_per_scan": 1, "rows_produced_per_join": 1, "filtered": "100.00", "cost_info": { "read_cost": "5.13", "eval_cost": "0.10", "prefix_cost": "5.23", "data_read_per_join": "440" }, "used_columns": [ "id", "rank1", "rank2", "log_time", "prefix_uid", "desc1", "rank3" ], "attached_condition": "((`ytt`.`t1`.`rank3` = 100) and (`ytt`.`t1`.`rank2` = 100) and (`ytt`.`t1`.`rank1` = 100))" } }}1 row in set, 1 warning (0.00 sec)
对比下以上两个，加了HINT的比不加HINT的cost小了100倍。
总结下，就是说表的cardinality值影响这张的查询计划，如果这个值没有正常更新的话，就需要手工加HINT了。相信MySQL未来的版本会带来更多的HINT。
