十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
方法
让客户满意是我们工作的目标,不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户,将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴,公司提供的服务项目有:国际域名空间、网络空间、营销软件、网站建设、佳木斯网站维护、网站推广。
(1) 根据需求找到关联表
(2)找到关联条件
重点的表tables
* 需求1:统计world库下有几个表
需求2:统计所有库下表的个数
需求3:统计每个库的总数据大小
--单表占空间:AVG_ROW_LENGTH*TABLE_ROWS+INDEX_LENGTH
什么使索引:索引其实就是一种算法
BTree
HASH
Rtree
Fulltext
辅助索引
辅助索引只提取索引列作为叶子节点
聚集索引
聚集索引提取整行数据作为叶子节点
1、辅助索引和聚集索引最大的区别就在于叶子节点,枝节点和根节点原理相同
2、辅助索引会记录主键值,一般情况(除等值查询),最终都会通过聚集索引(主键)来找到需要的数据
第二种
一般经常用来查询的列作为索引
索引可以有多个,但是索引名不可重名
第一种:单列索引
第二种:前缀索引
前缀索引只能应用到字符串列,数字列不能用前缀索引
联合索引说明:如果在一个表内对A、B、C三个列创建联合索引那么创建索引将按照如下情况创建索引表:
A
AB
ABC
======================================================
(1)查询列无索引
(2)语句不符合走走索引条件
(3)需要查看全表
即把有索引的列全便利一遍
、 、 =、 =、 like、 between and 在范围扫描中,这些会受到B+tree索引叶子节点上额外的优化,因为这些是连续取值的
or、in 这两个不是连续的取值,所以不能受到B+tree索引的额外优化,使用时相当于Btree索引
!=、 not in 只有在主键列才走索引也是range级别
(1)、 、 =、 =、 like、 between and
(2)or、in
(3)!=、 not in
多表连接查询,非驱动表连接条件是主键或唯一键
一般多表查询的时,最左侧的表为驱动表,右侧的为非驱动表,下边的例子中country标为非驱动表
7.1.1 数字类型
7.1.2 字符串类型:
字符集
中文
gbk 2字节
utf8 3字节
utf8mb4 4字节
utf8mb4 为例:
举例(1)联合索引等值查询
举例(2) 联合索引中有不等值查询
如果Extra列出现Using temporary、Using filesort,两项内容,那么考虑以下语句的问题。
group by
order by
distinct
join on
union
首先,MySql join连接可以连接两张或更多的数据表,但是并没有谁是“驱动表”之说。
Join分为"inner join"内连接和"outer join"外连接两种形式,外连接还可以进一步分为左连接和右连接。
内连接(inner join)只输出被连接的表它们的关联字段拥有交集的那些记录行,没交集的记录行将被剔除掉。
外连接(left join左连接/right join右连接):
"left join" 输出左表所有的记录行和右表之间关联字段拥有交集的记录行,对于右表找不到对应记录行的,数据库引擎会将空值Null赋值到右表的各个字段里。
"right join"的情况则于"left join" 刚好相反。
"inner join"——只输出表之间存在交集的那些记录行;
"left join" ——输出左表所有的记录行以及右表与之有交集的记录行,右表找不到对应
记录的,数据库引擎则将Null赋值到右表的各个字段;
"right join"——输出右表所有的记录行以及左表与之有交集的记录行,左表找不到对应
记录的,数据库引擎则将Null赋值到左表的各个字段;
=========================总结===========================
1.开启慢查询日志,设置阀值,比如超过5秒就是慢SQL,并把它抓取出来。
2.explain+慢SQL 分析
3.show profile 查询SQL在MySQL服务器里面的执行细节和声明周期。
显示mysql数据库表的内容需要把数据库中取到的sql内容用system.out.print。
以下是例子:
package test;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.SQLException;
import com.mysql.jdbc.Connection;
import com.mysql.jdbc.Statement;
/*使用JDBC连接数据库MySQL的过程
* DataBase:hj
* table:student
* */
public class Databasetest {
private static int count;
public static Connection getConnection() throws SQLException,
java.lang.ClassNotFoundException
{
//(1)加载MySQL的JDBC的驱动 Class.forName("com.mysql.jdbc.Driver");
//取得连接的url,能访问MySQL数据库的用户名,密码,数据库名
String url = "jdbc:mysql://127.0.0.1:3306/"+"hj?useUnicode=truecharacterEncoding=utf8";
String username = "root";
String password ="";
//(2)创建与MySQL数据库的连接类的实例
Connection con = (Connection) DriverManager.getConnection(url, username, password);
return con;
}
public static void main(String args[]) {
try
{
//(3)获取连接实例con,用con创建Statement对象实例 sql_statement
Connection con = getConnection();
Statement sql_statement = (Statement) con.createStatement();
//插入语句
String sql = "insert into student(id,name,score)values(null,'梵蒂冈的发',99)";
count=sql_statement.executeUpdate(sql);
//(4)执行查询,用ResultSet类的对象,返回查询结果
String query = "select * from student";
ResultSet result = sql_statement.executeQuery(query);
System.out.println("student表数据如下:");
System.out.println("------------------------");
System.out.println("学号" + " " + "姓名" + " " + "成绩");
System.out.println("------------------------");
//对获得的查询结果进行处理,对Result类的对象进行操作
while (result.next())
{
int number=result.getInt("id");
String name=result.getString("name");
String score=result.getString("score");
//取得数据库中的数据 System.out.println("学号: " + number + " 姓名: " + name + " 成绩: " + score);
}
//关闭连接和声明 sql_statement.close();
con.close();
} catch(java.lang.ClassNotFoundException e) {
//加载JDBC错误,所要用的驱动没有找到
System.err.print("ClassNotFoundException");
//其他错误
System.err.println(e.getMessage());
} catch (SQLException ex) {
//显示数据库连接错误或查询错误
System.err.println("SQLException: " + ex.getMessage());
}
}
}
运行结果:
student表数据如下:
------------------------
学号 姓名 成绩
001 张三 90
众所周知, MySQL的驱动表与被驱动表是优化器自动优化选择的结果 (与表连接的前后顺序等无关),我们可以用explain执行计划来知晓:
如上所示,前面一行t1是驱动表,后面一行t2是被驱动表。那么驱动表与被驱动表的选择是否有规律可循呢?下面是百度搜索两个主流的博文对驱动表与被驱动表的阐释:
1. MySQL连接查询驱动表被驱动表以及性能优化 - 阿伟~ - 博客园 博文A 主要结论:
2. mysql驱动表与被驱动表及join优化_java小小小黑的博客-CSDN博客_mysql驱动表和被驱动表 博文B 其主要结论:
两个帖子的结论是都差不多,而且还给出了例子来佐证。那么网上的结论是否权威?是否有普遍性?是否存在缺陷?
让我们来一起打破砂锅问到底。下面有两张表结构一模一样的表t1,t2:其中t1 100条数据,t2 1000条数据;t1(t2)结构如下:
按照上面博文的结论,left join左边是t2表,应该是驱动表。我们查看下结果:
与 博文B 中观点1相违背(同理观点2也违背),与实际不符,但究竟这是为什么呢?
下面发一张MySQL的执行过程(来源于《MySQL实战45讲》中01讲【一条SQL查询语句是如何执行的】)
so die si ne,原来sql执行的过程是这样呀。等等,不对,这跟刚才SQL又有什么关系,上面left join中t2表还是左边的呀。
我们知道MySQL高版本的性能越来越好,它是不断进行优化迭代的。远古的mysql版本可能还需要人工把小表放在前面,大表放在后面等这些需要人工调优的经验早就已经被解决了。也就是说我们写的语句,MySQL为了追求更好的效率,它在执行器执行前已经帮我们优化了。那么实际优化后的sql如何查看呢?用show warning命令:
其中Message就是优化后实际执行的sql语句,格式化后如下:
优化后left join左连接变成了内连接(inner) join。所以用优化后的sql看,表t1是小表所以作为驱动表,与实际结果相符。
left join 竟然优化成了join,太神奇了,但这是为什么呢?原因在于mysql中null与任何值做等值或者不等值比较的时候都是null,即使是select null=null 也是null。这样where 条件t1.a=t2.a查询条件不会包含t2.a为NULL的行,实际效果其实跟join一样,被优化器智能的优化了。
我们直接看执行计划看实际结果吧:
结果显示t2是驱动表,t1是被驱动表。t2是1000条数据按理说是大表应该是被驱动表,与 博文A , 博文B 的结论又不一致了。
《MySQL实战45讲》中34讲【到底可不可以使用join】已经讲的很透彻了,很深入了,我就不在这里献丑了。啰嗦几句大概就是驱动表是全表扫描不走索引,所以选被驱动表t1可以走索引,不会全表扫描,减少IO次数,性能高。里面对大表小表的总结,简直是精髓,特意在此再次着重强调:
在决定哪个表做驱动表的时候,应该是两个表按照各自的条件过滤,过滤完成之后,计算参与join的各个字段的总数据量,数据量小的那个表,就是“小表”,应该作为驱动表。
按照上面分析,我们先独立思考下MySQL会选择哪张表作为驱动表呢?
表t1,t2在字段a上都有索引不会全表扫描,其中t1.a=5条件过滤后只有一条,很显然嘛,t1数据量少是小表,肯定是驱动表,错不了,再说了前面的红色粗体已经强调了,不会有错的。
有冇搞错?事实又被打脸了。还记得在开篇我们说过的mysql优化器会对sql语句进行优化的吗?下面我们看下执行计划与优化的sql语句:
格式化后的优化SQL如下:
优化后两表t1,t2都走索引,并且都只有一条结果返回,因此都只会扫描一行,数据量一样,所以谁在前面谁就是驱动表,也就是上面sql中表t2。一切都释然,豁然开通!
回头再仔细想想,高,实在是高!仔细深思之后MySQL优化后的句子真让人猛拍大腿。高明之处在于:
1. 本来join连接是个M*N的嵌套循环,优化后变成了M+N的判断,两表不再嵌套判断了。
2. 优化后,两表没有多大必然联系,只需把两表的结果集拼接即可,互不干扰。如果mysql未来可以多线程查询,岂不十分快哉!
小伙伴们还记得我们在上一章 MySQL索引初探 中编码类型不一致发生隐式转换时有时候走索引,有时候索引又失效的问题吗?下面我们选取有代表性的一条记录来分析:
其中表demo_test总共有640条数据,demo_test_ass有3条数据。显然经过过滤条件t.rid1完成后demo_test_ass数据量小,应该作为驱动表。虽然test.c_utf8mb4 = t.c2两字段连接中发生了t.c2字段发生隐式转换,但是实际上并不影响被驱动表test上的c_utf8mb4索引。
好了,本章到此结束,让我们一起 总结一下MySQL驱动表与被驱动表的选取原则 :
หน ง 同等条件,优先选取有索引的表作为被驱动表。 在此介绍一下什么叫同等条件,比如上面的②中的语句。 两表没有其他额外的过滤条件,因此选关联字段有索引的t1作为被驱动表。但是如果加了条件(and t1.id=3),此时t1数据量少,就选取了t2作为被驱动表。
สอง MySQL选择驱动表与被驱动表是基于优化器优化后的,小表是驱动表,大表是被驱动表。 基于优化器优化后开篇的 博文A与B 结论成立。
当然这都是我一家之言,并不是官方结论,目前暂未找到官方确切对于驱动表与被驱动表的解释,请大家踊跃拍砖!