本文目录

• mysql数据库中，数据量很大的表，有什么优化方案么
• 如何使用phpMyadmin优化MySQL数据库
• Mysql怎样优化处理

mysql数据库中，数据量很大的表，有什么优化方案么

个人的观点，这种大表的优化，不一定上来就要分库分表，因为表一旦被拆分，开发、运维的复杂度会直线上升，而大多数公司是欠缺这种能力的。所以MySQL中几百万甚至小几千万的表，先考虑做单表的优化。

单表优化

单表优化可以从这几个角度出发：

• 表分区：MySQL在5.1之后才有的，可以看做是水平拆分，分区表需要在建表的需要加上分区参数，用户需要在建表的时候加上分区参数；分区表底层由多个物理子表组成，但是对于代码来说，分区表是透明的；SQL中的条件中最好能带上分区条件的列，这样可以定位到少量的分区上，否则就会扫描全部分区。

• 读写分离：最常用的优化手段，写主库读从库；

• 增加缓存：主要的思想就是减少对数据库的访问，缓存可以在整个架构中的很多地方，比如：数据库本身有就缓存，客户端缓存，数据库访问层对SQL语句的缓存，应用程序内的缓存，第三方缓存（如Redis等）；

• 字段设计：单表不要有太多字段；VARCHAR的长度尽量只分配真正需要的空间；尽量使用TIMESTAMP而非DATETIME；避免使用NULL，可以通过设置默认值解决。

• 索引优化：索引不是越多越好，针对性地建立索引，索引会加速查询，但是对新增、修改、删除会造成一定的影响；值域很少的字段不适合建索引；尽量不用UNIQUE，不要设置外键，由程序保证；

• SQL优化：尽量使用索引，也要保证不要因为错误的写法导致索引失效；比如：避免前导模糊查询，避免隐式转换，避免等号左边做函数运算，in中的元素不宜过多等等；

• NoSQL：有一些场景，可以抛弃MySQL等关系型数据库，拥抱NoSQL；比如：统计类、日志类、弱结构化的数据；事务要求低的场景。

表拆分

数据量进一步增大的时候，就不得不考虑表拆分的问题了：

• 垂直拆分：垂直拆分的意思就是把一个字段较多的表，拆分成多个字段较少的表；上文中也说过单表的字段不宜过多，如果初期的表结构设计的就很好，就不会有垂直拆分的问题了；一般来说，MySQL单表的字段最好不要超过二三十个。

• 水平拆分：就是我们常说的分库分表了；分表，解决了单表数据过大的问题，但是毕竟还在同一台数据库服务器上，所以IO、CPU、网络方面的压力，并不会得到彻底的缓解，这个可以通过分库来解决。水平拆分优点很明显，可以利用多台数据库服务器的资源，提高了系统的负载能力；缺点是逻辑会变得复杂，跨节点的数据关联性能差，维护难度大（特别是扩容的时候）。

希望我的回答，能够帮助到你！我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。

如何使用phpMyadmin优化MySQL数据库

phpMyadmin仅仅是一个数据库管理工具，与Mysql数据库优化应该是很松耦合的。下面简单谈谈MySql数据库的几个优化点：

1、优化SQL语句

比如尽量少用"select * from ..."，需要什么字段返回什么字段，可以有效节省网络IO，缩短查询时间，还可以增加Mysql服务器的吞吐量。

再比如需要select最近一个月的数据，数据量比较大；拆成10次请求，每次请求select三天的，效果可能会好很多。

再比如使用join做表连接的时候，尽量用小表驱动大表，简单来说就是left join，左表是驱动表；right join 右表是驱动表；inner join mysql会自动做优化

学会使用EXPLAIN关键字辅助优化

优化SQL语句是数据库优化的首选；

2、优化表结构

比如字段类型，可以用数字的字段，尽量不要用Text，比如订单Id一般都是数据。

小字段能满足要求的，尽量不要用大字段

根据业务场景，在合适的字段上添加索引，提高搜索速度

适当的做字段冗余和缩减

3、表的拆分

数据库表一般分为纵向拆分和横向拆分，纵向拆分就是将一个表按照列拆分成多个表，通过外键连接。横向拆分就是按照某个字段(比如：时间)做拆分。

数据库拆分

对于数据量太大，或者QPS很大的场景，就需要分库处理。比如设置主库和从库，主库用于写数据，从库用于读数据

以上优化手段，部分可以借助phpMyadmin实现。

更详细的优化手段欢迎点击我的头像，关注我，查看我之前写的Mysql系列文章。

大家觉得这个回答怎么样呢？？

Mysql怎样优化处理

1. 避免使用 select * 你需要什么信息,就查询什么信息,查询的多了,查询的速度肯定就会慢

2. 当你只需要查询出一条数据的时候,要使用 limit 1 比如你要查询数据中是否有男生,只要查询一条含有男生的记录就行了,后面不需要再查了,使用Limit 1 可以在找到一条数据后停止搜索

3. 建立高性能的索引 索引不是随便加的也不是索引越多越好,更不是所有索引对查询都有效

4. 建数据库表时,给字段设置固定合适的大小. 字段不能设置的太大,设置太大就造成浪费,会使查询速度变慢

5. 要尽量使用not null

6. EXPLAIN 你的 SELECT 查询 使用EXPLAIN,可以帮助你更了解MySQL是如何处理你的sql语句的, 你可以查看到sql的执行计划,这样你就能更好的去了解你的sql语句的不足,然后优化语句.

7. 在Join表的时候,被用来Join的字段，应该是相同的类型的,且字段应该是被建过索引的,这样，MySQL内部会启动为你优化Join的SQL语句的机制。

8. 如果你有一个字段，比如“性别”，“国家”，“民族”, “省份”，“状态”或“部门”，这些字段的取值是有限而且固定的，那么，应该使用 ENUM 而不是 VARCHAR。

因为在MySQL中，ENUM类型被当作数值型数据来处理，而数值型数据被处理起来的速度要比文本类型快得多。这样，我们又可以提高数据库的性能。

9. 垂直分割 将常用和有关系的字段放在相同的表中，把一张表的数据分成几张表 这样可以降低表的复杂度和字段的数目，从而达到优化的目的

10. 优化where查询

①. 避免在where子句中对字段进行表达式操作

比如： select 列 from 表 where age*2=36; 建议改成 select 列 from 表 where age=36/2;

②. 应尽量避免在 where 子句中使用 !=或 操作符，否则将引擎放弃使用索引而进行全表扫描。

③. 应尽量避免在 where 子句中对字段进行 null 值 判断

④. 应尽量避免在 where 子句中使用 or 来连接条件

11. 不建议使用%前缀模糊查询,这种查询会导致索引失效而进行全表扫描

例如LIKE “%name”或者LIKE “%name%这两种都是不建议的.但是可以使用LIKE “name%”。

对于LIKE “%name%,可以使用全文索引的形式

12. 要慎用in和 not in

例如：select id from t where num in(1,2,3) 建议改成 select id from t where num between 1 and 3

对于连续的数值，能用 between 就不要用 in 了

13. 理解in和exists， not in和not exists的区别

很多时候用 exists 代替 in 是一个好的选择：如查询语句使用了not in那么内外表都进行全表扫描，没用到索引，而not exists子查询依然能用到表上索引，所以无论哪个表大，用not exists都比not in要快。

select num from a where num in(select num from b)

建议改成: select num from a where exists(select 1 from b where num=a.num)

区分in和exists主要是造成了驱动顺序的改变（这是性能变化的关键），如果是exists，那么以外层表为驱动表，先被访问，如果是IN，那么先执行子查询。所以IN适合于外表大而内表小的情况；EXISTS适合于外表小而内表大的情况。

关于not in和not exists，推荐使用not exists，不仅仅是效率问题，not in可能存在逻辑问题

14. 理解select Count (*)和Select Count(1)以及Select Count(column)区别

一般情况下，Select Count (*)和Select Count(1)两着返回结果是一样的

假如表沒有主键(Primary key), 那么count(1)比count(*)快，

如果有主键的話，那主键作为count的条件时候count(主键)最快

如果你的表只有一个字段的话那count(*)就是最快的

count(*) 跟 count(1) 的结果一样，都包括对NULL的统计，而count(column) 是不包括NULL的统计

技术交流请关注“大数据java架构师”