MySQL对于成为一个非常快速的数据库服务器有着当之无愧的名声，它也非常容易设置和使用。随着它作为网站后端数据库得声望日增，其效果在去年开始有明显提高。但是很多MySQL用户更多地知道如何创建一个数据库并编写对它的查询。就像成千上万的人通过载闲暇时用Linux做实验来学习Unix那样，很多人通过玩MySQL学习关系数据库。这些MySQL新手的大多数既没有关系数据库理论的背景，又没有时间阅读MySQL手册全文。
因此，我们决定研究某些方法，你可以用针对优化性能来调节MySQL。在读完本文后，你将理解一些帮助你设计你的MySQL数据库和查询的技术，值得你的应用很有效率。我们将假定你熟悉MySQL和SQL基础，但不假定你有这两方面的广博知识。
只存储你需要的信息
这听上去是常识，但人们常常采取“厨房下水道”的方式进行数据库设计。他们认为可能项要得每样东西都要存储并设计数据库保存所有者这些数据。你需要对你的需求现实些，并确定取确实需要什么信息。你常常能随意产生一些数据而不把它存在数据库表中。在这种情况下，从一个应用开发者的角度看也有道理这样做。
例如，在线目录的产品表可能包含各种产品的名称、介绍、尺寸、重量和价格。除了价格，你可能想存储每个项目相关的税和运输成本。但实际上不必这样做。首先税和运输成本可以方便地（由你的应用或MySQL）计算出来。其次，如果税和运输成本改变了，你可能必须编写必要的查询更新每个产品记录中的税和运输的费率。
有时人们认为这太难不能在以后往数据库表中加入字段，所以他们感觉不得不定义尽可能多的列。这是明显的概念错误。在MySQL中，你可以用ALTER
TABLE命令方便地修改表定义以适应你改变的需求。
例如，如果你突然认识到你需要给你的产品表增加一个级别列（可能你想允许用户在你的目录中给产品评级），你可以这样做：
ALTER TABLE products ADD rank INTEGER
这给你的产品表增加了一个整数类型的级别列，你能用ALTER
TABLE做什么的完整介绍参见MySQL手册。
只要求你需要的东西--要清晰
就像说“只存储你需要的东西”那样，这可能看来是常识，但这一点常常被忽视，为什么呢？因为在一个应用开发时，需求经常改变，所以很多查询最终看来是这样：
SELECT * FROM sometable
当你不能肯定你将需要哪一列时，要求所有列明显是最省力的事情，然而随着你的表不断增大和修改，这可能变成一个性能问题。最好是在你的最初开发完成后再花些时间并确定你真正从你的查询中需要什么：
SELECT name, rank, description FROM products
这带来了一个相关的观点，即代码维护比性能更重要。大多数变成语言（Perl、Python、PHP、Java等）允许通过字段名和数字编号访问一条查询的结果，这意味着你可以访问命名字段或字段0都可以得到相同的数据。
长期看，最好使用列名而不是其编号位置，为什么？因为一个表中或一条查询中地列的相对位置可以改变。它们在表中可能因为重复使用ALTER
TABLE而改变，它们在查询中将因重写了查询而忘记更新应用逻辑来匹配而改变。
当然，你仍然需要小心改变列名！但如果你使用列名而非标号位置，如列名改变，你可以用grep搜索源代码或使用编辑器的搜索能力查找你需要修改的代码。
规范化你的表结构
如果你以前从未听说过“数据规范化”，不要害怕。规范化可能是一个复杂的专题，你可以从只理解最基本的规范化概念中正真正获益。
理解它的最容易的方法是认为你的表是一个电子报表。如果你想以一个报表跟踪你的CD收藏，你可以如图1种那样进行设计：
图1
album track1track2
track10
----- ------------
-------
Billboard Top Hits - 1984 Loverboy Shout St.
Elmo's Fire
(Billy Ocean) (Tears for Fears) (John
Parr)
这看上去很合理。大多数CD只有10首曲子，对否？不尽然。如果你拥有一张有100首曲子的CD且几张超过20首改怎么办。这意味着用这种方法，在极端的情况下，你将需要一个非常宽的表格（或一个超过100个字段的表）来保存所有的数据。
规范化表结构的目标是使“空单元”的数量最少，在上述CD表的情况下，如果你允许CD可能包含100首曲子，你会有很多这样的空单元。不
数据查询语言（凡是带有 select 关键字的都是查询语句）
select...
数据 *** 作语言（凡是对表中的 数据 进行增删改的都是 DML）
insert 增 delete 删 update 改
数据定义语言（凡是带有 create、drop、alter 的都是 DDL）
主要 *** 作的是 表的结构 ，不是表的数据
事务控制语言（包括：事务提交 commit、事务回滚 rollback）
数据控制语言（授权 grant、撤销权限 revoke）
select 字段 from 表名 where 条件
in(具体值，具体值，......) 不是区间
一个输入对应一个输出，和其对应的是多行处理函数（多个输入，对应一个输出）
输入多行，最终输出一行
如果你 没有对数据进行分组，整张表默认为一组 。
在实际的应用中，可能需要先进行分组，然后对每一组的数据进行 *** 作
案例： 查询每个员工所在部门的名称，显示员工名和部门名？
emp e 和 dept d 表进行连接。条件是：e.deptno = d.deptno
SQL92语法：（结构不够清晰，表的连接条件和后期进一步筛选的条件，都放到了 where 子句中）
SQL99语法：（表连接的条件是独立的，连接之后，如果还需要进一步筛选，再往后继续添加 where 子句）
技巧： 把一张表看成两张表
思考： 外连接的查询结果条数 >= 内连接的查询结果条数
select 语句中 嵌套 select 语句，被嵌套的 select 语句称为 子查询。
将查询结果集的一部分取出来。（通常使用在分页查询当中）
将字符串 varchar 类型转换成 date 类型
将日期转换成字符串
可以获取当前系统的时间，并且获取的时间是 datetime 类型的
注意：若没有条件限制将会导致所有数据全部更新。
注意：若没有条件，会删除整张表的数据。
constraint
not null 约束的字段 不能为 NULL （只有列级约束）
unique 约束的字段 不能重复 ，但是可以为 NULL
primary key
foreign key
transaction
实现原理 ：缩小扫描的范围（形成树），避免全表扫描
Database Administrator 数据库管理员
数据库表的设计依据。教你怎么进行数据库表的设计。
免费领取有关于java面试题材料和讲解！
Log File物理结构
从 ib_logfile0和 ib_logfile1这两个文件的物理结构可以看出，在Log Header部分还是有些许差异的， ib_logfile0会多一些额外的信息，主要是checkpoint信息。
并且每个Block的单位是512字节，对应到磁盘每个扇区也是512字节，因此redo log写磁盘是原子写，保证能够写成功，而不像index page一样需要double write来保证安全写入。
我们依次从上到下来看每个Block的结构
Log File Header Block
Log Goup ID，可能会配置多个redo组，每个组对应一个id，当前都是0，占用4字节
Start LSN，这个redo log文件开始日志的lsn，占用8字节
Log File Number，总是为0，占用4字节
Created By，备份程序所占用的字节数，占用32字节
另外在ib_logfile0中会有两个checkpoint block，分别是 LOG_CHECKPOINT_1/ LOG_CHECKPOINT_2，两个记录InnoDB Checkpoint信息的字段，分别从文件头的第二个和第四个block开始记录，并且只在每组log的第一个文件中存在，组内其他文件虽然没有checkpoint相关信息，但是也会预留相应的空间出来。这里为什么有两个checkpoint的呢？原因是设计为交替写入，避免因为介质失败而导致无法找到可用的checkpoint的情况。
Log blocks
请点击输入图片描述
log block结构分为日志头段、日志记录、日志尾部
Block Header，占用12字节
Data部分
Block tailer，占用4字节
Block Header
这个部分是每个Block的头部，主要记录的块的信息
Block Number，表示这是第几个block，占用4字节，是通过LSN计算得来的，占用4字节
Block data len，表示该block中有多少字节已经被使用了，占用2字节
First Rec offet，表示该block中作为第一个新的mtr开始的偏移量，占用2字节
Checkpoint number，表示该log block最后被写入时的检查点的值，占用4字节
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）