-
查看sql的执行计划：查看全部
-
慢查日志中需要关注的sql：查看全部
-
垂直拆分:一个表的列太多,可以分为多个表.. 水平拆分:一个表中的数据太多,分多表结构不变 为了解决单表数据量过大的问题，每个水平拆分表的结构完全一致 方法 1.对id进行hash运算，可以取mod 2.针对不同的hashId把数据放到不同的表中 水平拆分之后的挑战 1.跨分区进行数据查询 2。统计及后台报表操作 前后台使用的表进行分开，前台要求查询效率，所以可以说会用拆分之后的表，后台在统计数据时可以使用汇总表。查看全部
-
表的垂直拆分的原则 所谓垂直拆分，就是把原来一个有很多列的表拆分成多个表解决表的宽度问题，通常拆分原则如下： 1、把不常用的字段单独存放到一个表中 2、把大字段独立存放到一个表中 3、把经常一起使用的字段放到一起 当表的宽度过宽的时候，我们需要对表进行垂直拆分，具体的建议如下（原则上是人以群分，列以表分）：一表变多表，物理上不在一起，逻辑上是在一起的！查看全部
-
表的范式化即数据库设计的规范化：数据表不存在非关键字段对任意关键字段的传递函数依赖，则符合第三范式。 可以将一张数据表进行拆分，来满足第三范式的要求。 设计表的时候符合范式化是为了：减少数据冗余、减少表的插入、更新、删除异常 设计表的时候使用反范式化是为了：以空间换时间、增强代码的可编程性和可维护性 不符合第三范式要求的表存在以下问题： 1.数据冗余:（分类、分类描述）对于每一个商品都会进行记录 2.数据插入异常 3.数据更新异常 4.数据删除异常查看全部
-
选择合适的数据类型 1.使用可存下数据的最小的数据类型 2.使用简单地数据类型，Int要比varchar类型在mysql处理上更简单 3.尽可能使用not null定义字段，这是由innodb的特性决定的，因为非not null的数据可能需要一些额外的字段进行存储，这样就会增加一些IO。可以对非null的字段设置一个默认值 4.尽量少用text，非用不可最好分表，将text字段存放到另一张表中，在需要的时候再使用联合查询，这样可提高查询主表的效率 例子1、用Int存储日期时间 from_unixtime()可将Int类型的时间戳转换为时间格式 select from_unixtime(1392178320); 输出为 2014-02-12 12:12:00 unix_timestamp()可将时间格式转换为Int类型 select unix_timestamp('2014-02-12 12:12:00'); 输出为1392178320 例子2 存储IP地址——bigInt 利用inet_aton(),inet_ntoa()转换 select inet_aton('192.169.1.1'); 输出为3232301313 select inet_ntoa(3232301313); 输出为192.169.1.1查看全部
-
数据库结构优化 选择合适的数据类型 1.使用可存下数据的最小的数据类型 2.使用简单地数据类型，Int<varchar 3.尽可能使用not null定义字段 4.尽量少用text，非用不可最好分表 用Int存储日期时间 from_unixtime()可将Int类型的时间戳转换为时间格式 unix_timestamp()可将时间格式转换为Int类型 存储IP地址——bigInt 利用inet_aton(),inet_ntoa()转换查看全部
-
选择合适的索引列 1.在where，group by，order by，on从句中出现的列 2.索引字段越小越好(因为数据库的存储单位是页，一页中能存下的数据越多越好 ) 3.离散度大得列放在联合索引前面 select count(distinct customer_id), count(distinct staff_id) from payment;查看全部
-
group by可能会出现临时表（Using temporary），文件排序（Using filesort）等，影响效率。<br> 可以通过关联的子查询，来避免产生临时表和文件排序，可以节省io<br> 改写前<br> select actor.first_name,actor.last_name,count(*)<br> 注意：在数据库表中针对索引的查询往往比较快，所以，我们的查询或对于SQL语句优化要想到怎么才能利用上索引才好！ 经验丰富了才能更好的判断哪一种方式比较好，关键是思想要灵活要变通要学习，要有判断力要能把握住机会！ from sakila.film_actor<br> inner join sakila.actor using(actor_id)<br> group by film_actor.actor_id;<br> 改写后<br> select actor.first_name,actor.last_name,c.cnt<br> from sakila.actor inner join(<br> select actor_id,count(*) as cnt from sakila.film_actor group by<br> actor_id<br> )as c using(actor_id);查看全部
-
对于子查询的优化，可以优化成为join方式查询，但是这样子查询的话如果是一对多的关系，那么就要注意去重，可以用distinct关键字去重查看全部
-
利用max方法查询最后一笔交易的时间 explain select max(payment_date) from payment\G id:1 select_type:simple table:payment type:ALL (表扫描操作) possible_keys:null key:null key_len:null ref:null rows:15422 Extra: 这里就是一个表扫描操作，一共扫描了15422行数据。如果数据表很大，这里的IO效率就会很差 优化方法：max(field)可以通过为field建立索引 来优化 create index idx_paydate on payment(payment_date); 优化后： id:1 select_type:simple table:null type:null possible_keys:null key:null key_len:null ref:null rows:null Extra:select tables optimized away 优化之后并不需要查询表中的数据，而是通过索引就可以知道执行的结果了。 因为索引是顺序排列的，只需要查最后一个数据。这样就尽可能减少了IO操作。 而且这时候，不管表数据量有多大，查询max所需要的时间是基本固定的查看全部
-
Max()和Count()的优化 1.对max()查询，可以为表创建索引，create index index_name on table_name(column_name 规定需要索引的列),然后在进行查询 2.count()对多个关键字进行查询，比如在一条SQL中同时查出2006年和2007年电影的数量，语句： select count(release_year='2006' or null) as '2006年电影数量', count(release_year='2007' or null) as '2007年电影数量' from film;查看全部
-
extra：using filesort、using temporary（常出现在使用order by时）时需要优化，因为都是用了外部文件或者临时表的存储查看全部
-
table：表名；<br> type：连接的类型，const、eq_reg、ref、range、index和ALL；<br> const：主键、索引；eq_reg：主键、索引的范围查找；ref：连接的查找（join），range：索引的范围查找；index：索引的扫描；All：表扫描<br> possible_keys：可能用到的索引；<br> key：实际使用的索引；<br> key_len：索引的长度，越短越好；因为mysql每次的读取都是以页为单位，一页中的索引越大，查询的效率就越高<br> ref：索引的哪一列被使用了，常数较好；<br> rows：mysql认为必须检查的用来返回请求数据的行数；查看全部
-
找到相关的慢sql之后，如果对其进行优化 //mysql 数据库优化 explain分析sql的执行计划，并找出sql需要优化的地方查看全部
举报
0/150
提交
取消