sqlforce

A. 如何进行sql性能优化

这里分享下mysql优化的几种方法。

1、首先在打开的软件中，需要分别为每一个表创建 InnoDB FILE的文件。

B. 如何解决SQL查询速度太慢

1. 执行计划中明明有使用到索引，为什么执行还是这么慢？

2. 执行计划中显示扫描行数为 644，为什么 slow log 中显示 100 多万行？
a. 我们先看执行计划，选择的索引 “INDX_BIOM_ELOCK_TASK3(TASK_ID)”。结合 sql 来看，因为有 "ORDER BY TASK_ID DESC" 子句，排序通常很慢，如果使用了文件排序性能会更差，优化器选择这个索引避免了排序。
那为什么不选 possible_keys:INDX_BIOM_ELOCK_TASK 呢？原因也很简单，TASK_DATE 字段区分度太低了，走这个索引需要扫描的行数很大，而且还要进行额外的排序，优化器综合判断代价更大，所以就不选这个索引了。不过如果我们强制选择这个索引（用 force index 语法），会看到 SQL 执行速度更快少于 10s，那是因为优化器基于代价的原则并不等价于执行速度的快慢；
b. 再看执行计划中的 type:index，"index" 代表 “全索引扫描”，其实和全表扫描差不多，只是扫描的时候是按照索引次序进行而不是行，主要优点就是避免了排序，但是开销仍然非常大。
Extra:Using where 也意味着扫描完索引后还需要回表进行筛选。一般来说，得保证 type 至少达到 range 级别，最好能达到 ref。
在第 2 点中提到的“慢日志记录Rows_examined: 1161559，看起来是全表扫描”，这里更正为“全索引扫描”，扫描行数确实等于表的行数；
c. 关于执行计划中：“rows：644”，其实这个只是估算值，并不准确，我们分析慢 SQL 时判断准确的扫描行数应该以 slow log 中的 Rows_examined 为准。
4. 优化建议：添加组合索引 IDX_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID)

优化过程：
TASK_DATE 字段存在索引，但是选择度很低，优化器不会走这个索引，建议后续可以删除这个索引：
select count(*),count(distinct TASK_DATE) from T_BIOMA_ELOCK_TASK;+------------+---------------------------+| count(*) | count(distinct TASK_DATE) |+------------+---------------------------+| 1161559 | 223 |+------------+---------------------------+

在这个 sql 中 REL_DEVID 字段从命名上看选择度较高，通过下面 sql 来检验确实如此：
select count(*),count(distinct REL_DEVID) from T_BIOMA_ELOCK_TASK;+----------+---------------------------+| count(*) | count(distinct REL_DEVID) |+----------+---------------------------+| 1161559 | 62235 |+----------+---------------------------+

由于有排序，所以得把 task_id 也加入到新建的索引中，REL_DEVID,task_id 组合选择度 100%：
select count(*),count(distinct REL_DEVID,task_id) from T_BIOMA_ELOCK_TASK;+----------+-----------------------------------+| count(*) | count(distinct REL_DEVID,task_id) |+----------+-----------------------------------+| 1161559 | 1161559 |+----------+-----------------------------------+

在测试环境添加 REL_DEVID，TASK_ID 组合索引，测试 sql 性能：alter table T_BIOMA_ELOCK_TASK add index idx_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID);
添加索引后执行计划：
这里还要注意一点“隐式转换”：REL_DEVID 字段数据类型为 varchar，需要在 sql 中加引号：AND T.REL_DEVID = 000000025xxx >> AND T.REL_DEVID = '000000025xxx'

执行时间从 10s+ 降到 毫秒级别：
1 row in set (0.00 sec)
结论
一个典型的 order by 查询的优化，添加更合适的索引可以避免性能问题：执行计划使用索引并不意味着就能执行快。

C. sql 查询使用强制索引

使用强制索引的前提是必需有这个索引。你可以在索引里新建一个名称为f_type的索引 count查询速度很快的，不建议强制索引；另外，SQL分析器也会对查询进行优化，所以使用强制索引必要性不大

D. 在SQL中 如何正确使用各种联接查询

SELECT--SQL语法
从一个或多个表中检索数据。SELECT SQL 命令是与其它 Vfp一样的内置的 Vfp命令。当你使用 SELECT 来生成查询时, Vfp翻译查询并从表中获取指定数据。你可以从以下地方创建 SELECT 查询:

“命令”窗口中
带有其它任何 Vfp命令的 Vfp程序中
查询设计器中
SELECT [ALL | DISTINCT] [TOP nExpr [PERCENT]] [Alias.] Select_Item
[[AS] Column_Name] [, [Alias.] Select_Item [[AS] Column_Name] ...]
FROM [FORCE] [DatabaseName!] Table [[AS] Local_Alias]
[ [INNER | LEFT [OUTER] | RIGHT [OUTER] | FULL [OUTER] JOIN DatabaseName!]
Table [[AS] Local_Alias] [ON JoinCondition ...]
[[INTO Destination] | [TO FILE FileName [ADDITIVE] | TO PRINTER [PROMPT] | TO SCREEN]]
[PREFERENCE PreferenceName] [NOCONSOLE] [PLAIN] [NOWAIT]
[WHERE JoinCondition [AND JoinCondition ...] [AND | OR FilterCondition [AND | OR FilterCondition ...]]]
[Group By GroupColumn [, GroupColumn ...]] [HAVING FilterCondition] [UNION [ALL] SELECTCommand]
[Order By Order_Item [ASC | DESC] [, Order_Item [ASC | DESC] ...]]
参数
SELECT
在 SELECT 子句中指定在查询结果中包含的字段、常量和表达式。
ALL
查询结果中包含所有行 ( 包括重复值 )。ALL 是默认设置。
DISTINCT
在查询结果中剔除重复的行。每一个 SELECT 子句只能使用一次 DISTINCT。
TOP nExpr [PERCENT]
在符合查询条件的所有记录中，选取指定数量或百分比的记录。TOP 子句必须与 ORDER BY 子句同时使用。ORDER BY 子句指定查询结果中包含的列上由Top字句决定的行数， TOP 子句根据此排序选定最开始的 nExpr个或 nExpr% 的记录。

您可以指定选取 1 到 32767 个记录。使用 ORDER BY 子句指定的字段进行排序，会产生并列的情况，比如，可能有多个记录，它们在选定的字段上相同；所以，如果您指定 nExpr 为 10，在查询结果中可能多于 10 个记录，因为可能有几个记录位置并列。

如果包含 PERCENT 关键字指定查询结果中的记录数，得到记录数的可能是小数，这时进行取整。包含 PERCENT 关键字时，nExpr 的范围是 0.01 到 99.99。

[Alias.] Select_Item
限定匹配项的名称。Select_Item 指定的每一项在查询结果中都生成一列。一个项可以是以下一个
FROM 子句所包含的表中的字段名称。
一个常量，查询结果中每一行都出现这个常量值。
一个表达式，可以是用户自定义函数名。
关于使用用户定义函数的详细信息, 参见注释节中的带用户定义函数的 SELECT。

你用 Select_Item 指定的各项生成一个查询结果列。

如果两个或更多的项具有相同的名称, 在项名前包含表别名和一个句点来避免列重复。

[AS] Column_Name
为查询输出中的列指定显示名。Column_Name 可以是表达式但不能包含不允许的字符, 如, 字段名中的空格。
当 Select_Item 是一个表达式或包含一个字段函数而且你想给该列一个有意义的名字时该选项是有用的。

FROM [FORCE] DatabaseName!
列出所有从中检索数据的表。
FORCE 指定连接表时按它们出现在 FROM 子句中的顺序。如果省略 FORCE, Vfp会试图对查询进行优化。但是, 使用 FORCE 子句，避免了优化过程，可能加快查询执行的速度。

当包含表的数据库不是当前数据库时，DatabaseName! 指定这个数据库的名称。如果数据库不是当前数据库，就必须指定包含表的数据库名称。应在数据库名称之后表名之前加上感叹号(!)分隔符。

[[AS] Local_Alias]
为 Table 中的表指定一个临时名称。如果指定了本地别名，那么在整个SELECT 语句中必须都用这个别名代替表名。本地别名不影响 Visual FoxPro环境。INNER JOIN 只有在其他表中包含对应记录(一个或多个)的记录才出现在查询结果中。
INNER JOIN 只有在其他表中包含对应记录(一个或多个)的记录才出现在查询结果中。

LEFT [OUTER] JOIN 在查询结果中包含：JOIN 左侧表中的所有记录，以及JOIN 右侧表中匹配的记录。OUTER 关键字可被省略；包含 OUTER 强调这是一个外连接 (outer join)。

RIGHT [OUTER] JOIN 在查询结果中包含：JOIN 右侧表中的所有记录，以及 JOIN 左侧表中匹配的记录。OUTER 关键字可被省略；包含 OUTER 强调这是一个外连接接 (outer join)。

FULL [OUTER] JOIN 在查询结果中包含：JOIN 两侧所有的匹配记录，和不匹配的记录；包含 OUTER 强调这是一个外连接 (outer join)。

关于连接的详细信息, 参见备注段中的 Joins。

ON JoinCondition 指定连接条件。

INTO Destination
指定在何处保存查询结果。Destination 可以是下列子句之一:
ARRAY ArrayName ，将查询结果保存到变量数组中。
如果查询结果中不包含任何记录，则不创建这个数组。

CURSOR CursorName [NOFILTER | READWRITE] 将查询结果保存到临时表中。
要创建一个查用于子查询中的游标, 用 NOFILTER。关于 NOFILTER 的详细信息, 参见备注节。

要指定游标是临时的和可修改的, 使用 READWRITE。如果源表或表使用 autoincrementing, 该设置不会被 READWRITE 游标继承。

DBF | TABLE TableName [DATABASE DatabaseName [NAME LongTableName]] 保存查询结果到一个表中。
包含 DATABASE DatabaseName 以指定添加了表的数据库。

包含 NAME LongTableName 可以为该表命一个最多可包括 128 个字符的并且可以在数据库中代替短名字的长名。

如果没有包括 INTO 子句, 查询结果显示在一个“浏览”窗口中。也可以用 TO FILE 子句来定向查询结果到打印机或一个文件。

TO FILE FileName [ADDITIVE] | TO PRINTER [PROMPT] | TO SCREEN
定向查询结果到打印机或一个文件。
ADDITIVE 添加查询输出到 TO FILE FileName 中指定的已存在的文本文件内容中。

TO PRINTER 定向查询输出到一个打印机。在打印开始之前，使用可选的 PROMPT 子句显示一个对话框。您可以根据当前安装的打印机驱动程序调整打印机的设置。将 PROMPT 子句放置在紧跟 TO PRINTER 之后。

TO SCREEN 使查询结果定向输出到 Vfp主窗口或活动的用户自定义窗口中。

PREFERENCE PreferenceName
如果查询结果送往浏览窗口，就可以使用 PREFERENCE 保存浏览窗口的属性和选项以备后用。关于 PREFERENCE 功能的详细信息, 参见备注节。
NOCONSOLE
不显示送到文件、打印机或 Vfp主窗口的查询结果。
PLAIN
防止列标题出现在显示的查询结果中。不管有无 TO 子句都可使用 PLAIN子句。如果 SELECT 语句中包括 INTO 子句，则忽略 PLAIN 子句。
NOWAIT
打开浏览窗口并将查询结果输出到这个窗口后继续程序的执行。程序并不等待关闭浏览窗口，而是立即执行紧接在 SELECT 语句后面的程序行。关于如何使用 NOWAIT 的说明, 参见备注节。
WHERE JoinCondition
指定 Vfp的查询结果中只包括符合指定条件的记录。JoinCondition 指定位于 FROM 子句中的字段连接表。关于指定连接条件的详细信息, 参见备注节。
WHERE 支持 JoinCondition 的 ESCAPE 操作符, 让你可以执行包含有百分号 (%) 和下划线 (_) 通配符的 SELECT SQL 命令查询。ESCAPE 允许你指定一个按原字样处理的 SELECT SQL 命令通配符。在 ESCAPE 子句中, 一旦一个字符被放到通配符字符之前，就表示这个通配符被看作一个文字字符。

FilterCondition
指定将包含在查询结果中记录必须符合的条件。使用 AND 或 OR 操作符，您可以包含随意数目的过滤条件。您还可以使用 NOT 操作符将逻辑表达式的值取反，或使用 EMPTY() 函数以检查空字段。
SELECT SQL 命令在筛选条件中支持 "<field> IS / IS NOT NULL"。要学习如何使用 FilterCondition。

Group By GroupColumn [, GroupColumn ...]
按列的值对查询结果的行进行分组。GroupColumn 可以是常规的表字段名，也可以是一个包含 SQL 字段函数的字段名，还可以是一个数值表达式，指定查询结果表中的列位置(最左边的列编号为 1 )。
HAVING FilterCondition
指定包括在查询结果中的组必须满足的筛选条件。HAVING 应该同 GROUP BY一起使用。它能包含数量不限的筛选条件，筛选条件用 AND 或 OR 连接，还可以使用 NOT 来对逻辑表达式求反。可以在 HAVING 子句中使用本地别名和字段函数。 关于你可以使用的字段函数的详细信息, 参见备注节。FilterCondition 不能包含子查询。
可以使用带 HAVING 子句的 Group By。使用 HAVING 子句的命令如果没有使用 GROUP BY 子句，则它的作用与WHERE 子句相同。
如果 HAVING 子句不包含字段函数的话，使用 WHERE 子句可以获得较快的速度。

HAVING 子句应该出现在 INTO 子句前否则产生错误。

[UNION [ALL] SELECTCommand]
把一个 SELECT 语句的最后查询结果同另一个 SELECT 语句最后查询结果组合起来。默认情况下，UNION 检查组合的结果并排除重复的行。
要组合多个UNION 子句，可使用括号。可以用 UNION 子句模拟一个外部联接。
ALL 防止 UNION 删除组合结果中重复的行。

当一个列是备注或通用型时, 不允许连接不同类型的列。

在 Vfp8.0 以前的版本中, 当在两个不同类型的字段上执行 UNION 操作时你需要执行明确的转换。
Vfp现在对支持它的数据类型支持隐含数据类型转换。关于隐含数据类型转换和数据类型优先, UNION 子句允许的规则, 以及其它信息的详细内容, 参见备注节中的数据类型转换和优先。

Order By Order_Item [ASC | DESC]
根据列的数据对查询结果进行排序。每个 Order_Item 都必须对应查询结果中的一列。它可以是下列之一:
FROM 子句中表的字段，同时也是 SELECT 主句(不在子查询中)的一个选择项。
一个数值表达式，表示查询结果中列的位置(最左边列编号为 1 )。
ASC 指定查询结果根据排序项以升序排列。它是 ORDER BY 的默认选项。

DESC 指定查询结果以降序排列。

备注
在使用 FROM 子句时如果没有打开表, Vfp显示“打开”对话框让你指定文件位置。一但打开后, 表在查询完成后仍然保持打开。

当在 Destination 参数中使用 CURSOR 子句时, 如果你指定了一个打开的表的名字, Vfp产生一条错误信息。在 SELECT 执行后, 临时游标保持打开并是活动的和只读的除非你指定了 READWRITE 选项。当你关闭该临时游标时, 它被删除。游标可以指定 SORTWORK 而成为存在于驱动器或卷上的临时文件。

当在 Destination 参数中使用 CURSOR 子句时, 你现在可以使用 NOFILTER 来创建一个可用于后来的查询的游标。在早期版本的 Vfp中, 你需要包括一个额外的常数或表达式作为筛选。例如, 添加一个逻辑 true 作为筛选表达式来创建一个可用于后来的查询的查询:

SELECT *, .T. FROM customers INTO CURSOR myquery
但是, 包括 NOFILTER 会降低查询性能因为要在磁盘上创建一个临时表。临时表在游标关闭时从磁盘上删除。

当在 Destination 参数中使用 DBF | TABLE 子句时, 如果你指定了一个已经打开的表, 而且 SET SAFETY 是设置为 OFF, Vfp不警告地复写该表。如果你没有指定一个扩展名, Vfp给表一个 .dbf 扩展名。在 SELECT 执行后表保持打开并且是活动的。

如果你在相同查询中包括 INTO 和 TO 子句, Vfp忽略 TO 子句。如果你包括 TO 子句但没有包括 INTO 子句, 你可以定向查询结果到一个名为 FileName 的 ASCII 文本文件, 到打印机, 或到 Vfp主窗口。

PREFERENCE 把特征, 属性或参数选项长期保存在 FoxUser.dbf 资源文件中。Preferences 可以在任何时候获取。第一次执行有 PREFERENCE Preference Name 的 SELECT 命令时创建参数选项。以后执行有相同参数选项名的 SELECT 命令时便将浏览窗口恢复到原来的参数选项状态。当浏览窗口关闭时，更新参数选项。如果您按下 CTRL+Q+W 键退出“浏览”窗口，您对“浏览”窗口所做的更改不会保存到资源文件中。

SELECT 命令中包括 TO SCREEN 可以把查询结果定向输出到 Vfp主窗口或用户自定义窗口。如果显示时 Vfp主窗口或用户自定义窗口中写满了一屏，就暂停输出。按任意键可以查看查询结果后面的内容。但是，如果命令中包括了 NOWAIT 子句，显示查询结果时就不会暂停，等待按键，而是在 Vfp主窗口或用户自定义窗口中连续滚过所有内容。如果命令中包含有 INTO 子句，忽略 NOWAIT 子句。

在一个 SQL 查询的 WHERE 子句中包括 EVALUATE() 函数会返回不正确的数据。

如果包括一个以上的表在查询中, 你应该在第一个以后为每一个表指定一个连接条件。连接条件可以包含筛选条件。

注意 每一个 SELECT 语句的最大连接数是 9.
必须用 AND 操作符来连接多个连接条件。各连接条件具有以下格式:

当你在串中使用 = 操作符时, 它的动作根据 SET ANSI 的设置会不同。当 SET ANSI 设置为 OFF 时, Vfp只比较串到较短串结束。当 SET ANSI 设置为 ON 时, Vfp遵循 ANSI 标准的字符串比较。关于 Vfp如果执行字符串比较的额外信息, 参见 SET ANSI 和 SET EXACT。

下列字段函数可以与选定项一起使用，选定项可以是一个字段或包含字段的表达式:

AVG(Select_Item), 计算列中数值的平均值。
COUNT(Select_Item), 计算列中选定项的数目。计算查询输出的行数。COUNT(*) 计算查询输出中的行数。
MIN(Select_Item), 确定列中 Select_Item 的最小值。
MAX(Select_Item), 确定列中 Select_Item 的最大值。
SUM(Select_Item), 计算列中数值的和。
字段函数不能嵌套使用。

UNION 子句遵守下列规则:

不能使用 UNION 来组合子查询。
两个 SELECT 命令的查询结果中的列数必须相同。
两个 SELECT 查询结果中的对应列必须有相同的数据类型和宽度。
只有最后的 SELECT 中可以包含 ORDER BY 子句，而且必须按编号指出所输出的列。如果包含了一个 ORDER BY 子句，它将影响整个结果。
当你用 UNION 连接查询中的两个表时, 仅匹配连接字段值的记录会出现在查询结果中。如果在父表中的记录在子表中没有相应的记录, 父表中的记录不会出现在查询结果中。一个外部联接允许你包括父表中的所有记录到输出结果中, 连同子表中的匹配记录一起。要在 Vfp中创建一个外部联接, 你需要要使用一个嵌套的 SELECT 命令
注意 确信在每一个分号前包括一个空格。否则, Vfp产生一个错误。
上例中, 在 UNION 子句前的部分的命令从两个表中选择具有匹配值的记录。不包括没有相关的发票的客户公司。命令中 UNION 子句后的部分选择客户表中的在订单表中无匹配记录的记录。

关于第二部分的命令, 注意以下几点:

包括在园括号中的 SELECT 语句首先处理。该语句的结果是选择订单表中的所有客户编号。
WHERE 子句找出 customer 表中的在 orders 表没有相关记录的所有客户编号。由于第一节中的命令提供了所在 orders 表中有客户编号的公司, Customer 表中的所有公司现在都包含在查询结果中了。
因为在 UNION 中的表的结构必须相同, 有两个占位符在第二个 SELECT 语句中来代表第一个 SELECT 语句中的 orders.order_id 和 orders.emp_id。
注意 占位符必须与它们所代表的字段有相同类型。如果字段是日期型, 占位符应该是 。如果字段是一个字符字段, 占位符应该是一个空串 ("")。

如果你没有在 Order By 子句中指定排序, 查询结果显示为未排序。

当你发出 SET TALK ON 并执行 SELECT 时, Vfp显示查询使用的时间和结果中的记录数。 _TALLY 包含了在查询结果中的记录数。

SET FILTER 设置的筛选条件对 SELECT 命令不起作用。

注意 下面部分提到的子查询, 是指在 SELECT 命令中包含的 SELECT 命令。子查询必须包括在园括号中。在 SELECT 命令的 WHERE 子句中可以包含最多两个平级的(非嵌套)的子查询。子查询中可以有多个连接条件 (join conditions)。
在你创建查询输出时, 列的命名遵循如下规则:

如果选择项是具有唯一名称的字段，则用字段名作为输出列名。
如果多个选择项具有相同名称。例如，如果名为 Customer 的表有一个STREET 字段，而名为 Employees 的表也有一个 STREET 字段，则输出列命名为 Extension_A 和 Extension_B (STREET_A 和 STREET_B)。如果选择项名称有 10 字符长，可以将名称截短后再加下划线和字母。例如，DEPARTMENT 变为 DEPARTME_A。
如果选择项是表达式，它的输出列命名为 EXP_A。其他表达式分别命名为EXP_B、EXP_C，依此类推。
如果选择项包含诸如 COUNT() 这样的字段函数，则输出列命名为CNT_A。如果另一个选择项包含 SUM()，它的输出列命名为 SUM_B。
用户定义函数和 在 SELECT 子句中使用用户自定义函数有明显优点，但使用时应考虑以下限制:

SELECT 子句的运行速度会受用户自定义函数执行速度的影响。因此，如果使用户自定义函数的操作量很大，则这些函数的功能最好调用 C 语言或汇编语言编写的 API 或用户自定义函数来完成。
在 SELECT 激活的用户自定义函数中，很难预测 Vfp输入/输出(I/O)和表的环境。一般来说，不知道选择的工作区是哪一个，不知道当前表的名称，甚至不知道正在处理的字段名。这些变量的值完全取决于用户自定义函数在优化过程的什么地方激活。
在 SELECT 子句调用的用户自定义函数中修改 VfpI/O 或表的环境是很不安全的。一般来说，这样做的结果难以预料。
从 SELECT 将值传递给用户自定函数唯一可靠的方法，是激活用户自定义函数时以参数的形式传递。
经过实践，有可能发现某种被认为是违法的操作在某种 FoxPro 版本中运行正确，但这并不保证它在以后的版本中也能正确运行。
抛开这些限制不说，用户自定义函数在 SELECT 语句中还是可接受的。但不要忘记使用 SELECT 可能要降低性能。要学习如何在 SELECT 中使用用户定义函数, 参见示例节。

连接 Vfp支持 ANSI SQL '92 连接 (Join) 语法，通过比较两个或多个表中的字段，将它们的记录连接到一起，生成查询。例如，内部连接 (inner join) 是将两个表中连接字段 (joined field) 值相同的记录选取到查询中。Vfp支持嵌套连接(nested joins)

由于 SQL 是派生于数学集合理论, 各表可以代表一个环。指定连接条件的 ON 子句确定交接点, 它代表匹配的行集合。对于一个内部联接, 交接发生在两个环的内部或 "inner" 部分。一个外联接不仅仅包括这些表内部的交叉区域匹配的行, 也包括环的外面的左或右部的交集的行。

E. SQL语句执行过程详解

SQL语句执行过程详解
一条sql，plsql的执行到底是怎样执行的呢？
一、SQL语句执行原理：
第一步:客户端把语句发给服务器端执行当我们在客户端执行 select 语句时,客户端会把这条 SQL 语句发送给服务器端,让服务器端的
进程来处理这语句。也就是说,Oracle 客户端是不会做任何的操作,他的主要任务就是把客户端产生
的一些 SQL 语句发送给服务器端。虽然在客户端也有一个数据库进程,但是,这个进程的作用跟服务器
上的进程作用事不相同的。服务器上的数据库进程才会对SQL 语句进行相关的处理。不过,有个问题需
要说明,就是客户端的进程跟服务器的进程是一一对应的。也就是说,在客户端连接上服务器后,在客户
端与服务器端都会形成一个进程,客户端上的我们叫做客户端进程;而服务器上的我们叫做服务器进程。
第二步:语句解析
当客户端把 SQL 语句传送到服务器后,服务器进程会对该语句进行解析。同理,这个解析的工作,
也是在服务器端所进行的。虽然这只是一个解析的动作,但是,其会做很多“小动作”。
1. 查询高速缓存(library cache)。服务器进程在接到客户端传送过来的 SQL 语句时,不
会直接去数据库查询。而是会先在数据库的高速缓存中去查找,是否存在相同语句的执行计划。如果在
数据高速缓存中,则服务器进程就会直接执行这个 SQL 语句,省去后续的工作。所以,采用高速数据缓
存的话,可以提高 SQL 语句的查询效率。一方面是从内存中读取数据要比从硬盘中的数据文件中读取
数据效率要高,另一方面,也是因为这个语句解析的原因。
不过这里要注意一点,这个数据缓存跟有些客户端软件的数据缓存是两码事。有些客户端软件为了
提高查询效率,会在应用软件的客户端设置数据缓存。由于这些数据缓存的存在,可以提高客户端应用软
件的查询效率。但是,若其他人在服务器进行了相关的修改,由于应用软件数据缓存的存在,导致修改的
数据不能及时反映到客户端上。从这也可以看出,应用软件的数据缓存跟数据库服务器的高速数据缓存
不是一码事。
2. 语句合法性检查(data dict cache)。当在高速缓存中找不到对应的 SQL 语句时,则服
务器进程就会开始检查这条语句的合法性。这里主要是对 SQL 语句的语法进行检查,看看其是否合乎
语法规则。如果服务器进程认为这条 SQL 语句不符合语法规则的时候,就会把这个错误信息,反馈给客
户端。在这个语法检查的过程中,不会对 SQL 语句中所包含的表名、列名等等进行 SQL 他只是语法
上的检查。
3. 语言含义检查(data dict cache)。若 SQL 语句符合语法上的定义的话,则服务器进程
接下去会对语句中的字段、表等内容进行检查。看看这些字段、表是否在数据库中。如果表名与列名不
准确的话,则数据库会就会反馈错误信息给客户端。所以,有时候我们写 select 语句的时候,若语法
与表名或者列名同时写错的话,则系统是先提示说语法错误,等到语法完全正确后,再提示说列名或表名
错误。
4. 获得对象解析锁(control structer)。当语法、语义都正确后,系统就会对我们需要查询
的对象加锁。这主要是为了保障数据的一致性,防止我们在查询的过程中,其他用户对这个对象的结构发
生改变。
5. 数据访问权限的核对(data dict cache)。当语法、语义通过检查之后,客户端还不一定
能够取得数据。服务器进程还会检查,你所连接的用户是否有这个数据访问的权限。若你连接上服务器
的用户不具有数据访问权限的话,则客户端就不能够取得这些数据。有时候我们查询数据的时候,辛辛苦
苦地把 SQL 语句写好、编译通过,但是,最后系统返回个 “没有权限访问数据”的错误信息,让我们气
半死。这在前端应用软件开发调试的过程中,可能会碰到。所以,要注意这个问题,数据库服务器进程先
检查语法与语义,然后才会检查访问权限。
6. 确定最佳执行计划 ?。当语句与语法都没有问题,权限也匹配的话,服务器进程还是不会直接对
数据库文件进行查询。服务器进程会根据一定的规则,对这条语句进行优化。不过要注意,这个优化是有
限的。一般在应用软件开发的过程中,需要对数据库的 sql 语言进行优化,这个优化的作用要大大地大
于服务器进程的自我优化。所以,一般在应用软件开发的时候,数据库的优化是少不了的。当服务器进程
的优化器确定这条查询语句的最佳执行计划后,就会将这条 SQL 语句与执行计划保存到数据高速缓存
(library cache)。如此的话,等以后还有这个查询时,就会省略以上的语法、语义与权限检查的步骤,
而直接执行 SQL 语句,提高 SQL 语句处理效率。
第三步:语句执行
语句解析只是对 SQL 语句的语法进行解析,以确保服务器能够知道这条语句到底表达的是什么意
思。等到语句解析完成之后,数据库服务器进程才会真正的执行这条 SQL 语句。这个语句执行也分两
种情况。
一是若被选择行所在的数据块已经被读取到数据缓冲区的话,则服务器进程会直接把这个数据传递
给客户端,而不是从数据库文件中去查询数据。
若数据不在缓冲区中,则服务器进程将从数据库文件中查询相关数据,并把这些数据放入到数据缓冲
区中(buffer cache)。
第四步:提取数据
当语句执行完成之后,查询到的数据还是在服务器进程中,还没有被传送到客户端的用户进程。所以,
在服务器端的进程中,有一个专门负责数据提取的一段代码。他的作用就是把查询到的数据结果返回给
用户端进程,从而完成整个查询动作。从这整个查询处理过程中,我们在数据库开发或者应用软件开发过
程中,需要注意以下几点:
一是要了解数据库缓存跟应用软件缓存是两码事情。数据库缓存只有在数据库服务器端才存在,在
客户端是不存在的。只有如此,才能够保证数据库缓存中的内容跟数据库文件的内容一致。才能够根据
相关的规则,防止数据脏读、错读的发生。而应用软件所涉及的数据缓存,由于跟数据库缓存不是一码事
情,所以,应用软件的数据缓存虽然可以提高数据的查询效率,但是,却打破了数据一致性的要求,有时候
会发生脏读、错读等情况的发生。所以,有时候,在应用软件上有专门一个功能,用来在必要的时候清除
数据缓存。不过,这个数据缓存的清除,也只是清除本机上的数据缓存,或者说,只是清除这个应用程序
的数据缓存,而不会清除数据库的数据缓存。
二是绝大部分 SQL 语句都是按照这个处理过程处理的。我们 DBA 或者基于 Oracle 数据库的
开发人员了解这些语句的处理过程,对于我们进行涉及到 SQL 语句的开发与调试,是非常有帮助的。有
时候,掌握这些处理原则,可以减少我们排错的时间。特别要注意,数据库是把数据查询权限的审查放在
语法语义的后面进行检查的。所以,有时会若光用数据库的权限控制原则,可能还不能满足应用软件权限
控制的需要。此时,就需要应用软件的前台设置,实现权限管理的要求。而且,有时应用数据库的权限管
理,也有点显得繁琐,会增加服务器处理的工作量。因此,对于记录、字段等的查询权限控制,大部分程
序涉及人员喜欢在应用程序中实现,而不是在数据库上实现。
DBCC DROPCLEANBUFFERS
从缓冲池中删除所有清除缓冲区。
DBCC FREEPROCCACHE
从过程缓存中删除所有元素。
DBCC FREESYSTEMCACHE
从所有缓存中释放所有未使用的缓存条目
SQL语句中的函数、关键字、排序等执行顺序:
1. FROM 子句返回初始结果集。
2. WHERE 子句排除不满足搜索条件的行。
3. GROUP BY 子句将选定的行收集到 GROUP BY 子句中各个唯一值的组中。
4. 选择列表中指定的聚合函数可以计算各组的汇总值。
5. 此外,HAVING 子句排除不满足搜索条件的行。
6. 计算所有的表达式;
7. 使用 order by 对结果集进行排序。
8. 查找你要搜索的字段。
二、SQL语句执行完整过程：
1.用户进程提交一个 sql 语句:
update temp set a=a*2，给服务器进程。
2.服务器进程从用户进程把信息接收到后,在 PGA 中就要此进程分配所需内存,存储相关的信息,如在会
话内存存储相关的登录信息等。
3.服务器进程把这个 sql 语句的字符转化为 ASCII 等效数字码,接着这个 ASCII 码被传递给一个
HASH 函数,并返回一个 hash 值,然后服务器进程将到shared pool 中的 library cache 中去查找是否存在相
同的 hash 值,如果存在,服务器进程将使用这条语句已高速缓存在 SHARED POOL 的library cache 中的已
分析过的版本来执行。
4.如果不存在,服务器进程将在 CGA 中,配合 UGA 内容对 sql,进行语法分析,首先检查语法的正确性,接
着对语句中涉及的表,索引,视图等对象进行解析,并对照数据字典检查这些对象的名称以及相关结构，并根据
ORACLE 选用的优化模式以及数据字典中是否存在相应对象的统计数据和是否使用了存储大纲来生成一个
执行计划或从存储大纲中选用一个执行计划,然后再用数据字典核对此用户对相应对象的执行权限,最后生成
一个编译代码。
5.ORACLE 将这条 sql 语句的本身实际文本、HASH 值、编译代码、与此语名相关联的任何统计数据
和该语句的执行计划缓存在 SHARED POOL 的 library cache中。服务器进程通过 SHARED POOL 锁存
器(shared pool latch)来申请可以向哪些共享 PL/SQL 区中缓存这此内容,也就是说被SHARED POOL 锁存
器锁定的 PL/SQL 区中的块不可被覆盖,因为这些块可能被其它进程所使用。
6.在 SQL 分析阶段将用到 LIBRARY
CACHE,从数据字典中核对表、视图等结构的时候,需要将数据
字典从磁盘读入 LIBRARY
CACHE,因此,在读入之前也要使用LIBRARY
CACHE 锁存器(library cache
pin,library cache lock)来申请用于缓存数据字典。 到现在为止,这个 sql 语句已经被编译成可执行的代码了,
但还不知道要操作哪些数据,所以服务器进程还要为这个 sql 准备预处理数据。
7.首先服务器进程要判断所需数据是否在 db buffer 存在,如果存在且可用,则直接获取该数据,同时根据
LRU 算法增加其访问计数;如果 buffer 不存在所需数据,则要从数据文件上读取首先服务器进程将在表头部
请求 TM 锁(保证此事务执行过程其他用户不能修改表的结构),如果成功加 TM 锁,再请求一些行级锁(TX
锁),如果 TM、TX 锁都成功加锁,那么才开始从数据文件读数据,在读数据之前,要先为读取的文件准备好
buffer 空间。服务器进程需要扫面 LRU list 寻找 free db buffer,扫描的过程中,服务器进程会把发现的所有
已经被修改过的 db buffer 注册到 dirty list 中, 这些 dirty buffer 会通过 dbwr 的触发条件,随后会被写出到
数据文件,找到了足够的空闲 buffer,就可以把请求的数据行所在的数据块放入到 db buffer 的空闲区域或者
覆盖已经被挤出 LRU list 的非脏数据块缓冲区,并排列在 LRU list 的头部,也就是在数据块放入 DB
BUFFER 之前也是要先申请 db buffer 中的锁存器,成功加锁后,才能读数据到 db buffer。
8.记日志 现在数据已经被读入到 db buffer 了,现在服务器进程将该语句所影响的并被读
入 db buffer 中的这些行数据的 rowid 及要更新的原值和新值及 scn 等信息从 PGA 逐条的写入 redo log
buffer 中。在写入 redo log buffer 之前也要事先请求 redo log buffer 的锁存器,成功加锁后才开始写入,当
写入达到 redo log buffer 大小的三分之一或写入量达到 1M 或超过三秒后或发生检查点时或者 dbwr 之前
发生,都会触发 lgwr 进程把 redo log buffer 的数据写入磁盘上的 redo file 文件中(这个时候会产生log file
sync 等待事件)
已经被写入 redofile 的 redo log buffer 所持有的锁存器会被释放,并可被后来的写入信息覆盖,
redo log buffer是循环使用的。Redo file 也是循环使用的,当一个 redo file 写满后,lgwr 进程会自动切换到
下一 redo file(这个时候可能出现 log fileswitch(checkpoint complete)等待事件)。如果是归档模式,归档进
程还要将前一个写满的 redo file 文件的内容写到归档日志文件中(这个时候可能出现 log file
switch(archiving needed)。
9.为事务建立回滚段 在完成本事务所有相关的 redo log buffer 之后,服务器进程开始改写这个 db buffer
的块头部事务列表并写入 scn,然后 包含这个块的头部事务列表及 scn 信息的数据副本放入回滚段中,将
这时回滚段中的信息称为数据块的“前映像“,这个”前映像“用于以后的回滚、恢复和一致性读。(回滚段可以
存储在专门的回滚表空间中,这个表空间由一个或多个物理文件组成,并专用于回滚表空间,回滚段也可在其它
表空间中的数据文件中开辟。
10.本事务修改数据块 准备工作都已经做好了,现在可以改写 db buffer 块的数据内容了,并在块的头部写
入回滚段的地址。
11.放入 dirty list 如果一个行数据多次 update 而未 commit,则在回滚段中将会有多个“前映像“,除了第
一个”前映像“含有 scn 信息外,其他每个“前映像“的头部都有 scn 信息和“前前映像”回滚段地址。一个
update 只对应一个 scn,然后服务器进程将在 dirty list 中建立一
条指向此 db buffer 块的指针(方便 dbwr 进程可以找到 dirty list 的 db buffer 数据块并写入数据文件中)。
接着服务器进程会从数据文件中继续读入第二个数据块,重复前一数据块的动作,数据块的读入、记日志、建
立回滚段、修改数据块、放入 dirty list。当 dirty queue 的长度达到阀值(一般是 25%),服务器进程将通知
dbwr 把脏数据写出,就是释放 db buffer 上的锁存器,腾出更多的 free db buffer。前面一直都是在说明
oracle 一次读一个数据块,其实 oracle 可以一次读入多个数据块(db_file_multiblock_read_count 来设置一
次读入块的个数)
说明:
在预处理的数据已经缓存在 db buffer 或刚刚被从数据文件读入到 db buffer 中,就要根据 sql 语句
的类型来决定接下来如何操作。
1>如果是 select 语句,则要查看 db buffer 块的头部是否有事务,如果有事务,则从回滚段中读取数据;如
果没有事务,则比较 select 的 scn 和 db buffer 块头部的 scn,如果前者小于后者,仍然要从回滚段中读取数据;
如果前者大于后者,说明这是一非脏缓存,可以直接读取这个 db buffer 块的中内容。
2>如果是 DML 操作,则即使在 db buffer 中找到一个没有事务,而且 SCN 比自己小的非脏
缓存数据块,服务器进程仍然要到表的头部对这条记录申请加锁,加锁成功才能进行后续动作,如果不成功,则要
等待前面的进程解锁后才能进行动作(这个时候阻塞是 tx 锁阻塞)。
用户 commit 或 rollback 到现在为止,数据已经在 db buffer 或数据文件中修改完
成,但是否要永久写到数文件中,要由用户来决定 commit(保存更改到数据文件) rollback 撤销数据的更改)。
1.用户执行 commit 命令
只有当 sql 语句所影响的所有行所在的最后一个块被读入 db buffer 并且重做信息被写入 redo log
buffer(仅指日志缓冲区,而不包括日志文件)之后,用户才可以发去 commit 命令,commit 触发 lgwr 进程,但不
强制立即 dbwr来释放所有相应 db buffer 块的锁(也就是no-force-at-commit,即提交不强制写),也就是说有
可能虽然已经 commit 了,但在随后的一段时间内 dbwr 还在写这条 sql 语句所涉及的数据块。表头部的行锁
并不在 commit 之后立即释放,而是要等 dbwr 进程完成之后才释放,这就可能会出现一个用户请求另一用户
已经 commit 的资源不成功的现象。
A .从 Commit 和 dbwr 进程结束之间的时间很短,如果恰巧在 commit 之后,dbwr 未结束之前断电,因为
commit 之后的数据已经属于数据文件的内容,但这部分文件没有完全写入到数据文件中。所以需要前滚。由
于 commit 已经触发 lgwr,这些所有未来得及写入数据文件的更改会在实例重启后,由 smon 进程根据重做日
志文件来前滚,完成之前 commit 未完成的工作(即把更改写入数据文件)。
B.如果未 commit 就断电了,因为数据已经在 db buffer 更改了,没有 commit,说明这部分数据不属于数
据文件,由于 dbwr 之前触发 lgwr 也就是只要数据更改,(肯定要先有 log) 所有 DBWR,在数据文件上的修改
都会被先一步记入重做日志文件,实例重启后,SMON 进程再根据重做日志文件来回滚。
其实 smon 的前滚回滚是根据检查点来完成的,当一个全部检查点发生的时候,首先让 LGWR 进程将
redo log buffer 中的所有缓冲(包含未提交的重做信息)写入重做日志文件,然后让 dbwr 进程将 db buffer 已
提交的缓冲写入数据文件(不强制写未提交的)。然后更新控制文件和数据文件头部的 SCN,表明当前数据库
是一致的,在相邻的两个检查点之间有很多事务,有提交和未提交的。
像前面的前滚回滚比较完整的说法是如下的说明:

A.发生检查点之前断电,并且当时有一个未提交的改变正在进行,实例重启之后,SMON 进程将从上一个
检查点开始核对这个检查点之后记录在重做日志文件中已提交的和未提交改变,因为
dbwr 之前会触发 lgwr,所以 dbwr 对数据文件的修改一定会被先记录在重做日志文件中。因此,断电前被
DBWN 写进数据文件的改变将通过重做日志文件中的记录进行还原,叫做回滚,
B. 如果断电时有一个已提交,但 dbwr 动作还没有完全完成的改变存在,因为已经提交,提交会触发 lgwr
进程,所以不管 dbwr 动作是否已完成,该语句将要影响的行及其产生的结果一定已经记录在重做日志文件中
了,则实例重启后,SMON 进程根据重做日志文件进行前滚.
实例失败后用于恢复的时间由两个检查点之间的间隔大小来决定,可以通个四个参数设置检查点执行的频
率:

Log_checkpoint_interval:
决定两个检查点之间写入重做日志文件的系统物理块(redo blocks)
的大小,默认值是 0,无限制。
log_checkpoint_timeout:
两 个 检 查 点 之 间 的 时 间 长 度（秒）默 认 值 1800s。
fast_start_io_target:
决定了用于恢复时需要处理的块的多少,默认值是 0,无限制。
fast_start_mttr_target:
直接决定了用于恢复的时间的长短,默认值是 0,无限制(SMON 进程执行的前滚
和回滚与用户的回滚是不同的,SMON 是根据重做日志文件进行前滚或回滚,而用户的回滚一定是根据回滚段
的内容进行回滚的。
在这里要说一下回滚段存储的数据,假如是 delete 操作,则回滚段将会记录整个行的数据,假如是 update,
则回滚段只记录被修改了的字段的变化前的数据(前映像),也就是没有被修改的字段是不会被记录的,假如是
insert,则回滚段只记录插入记录的 rowid。 这样假如事务提交,那回滚段中简单标记该事务已经提交;假如是
回退,则如果操作是 delete,回退的时候把回滚段中数据重新写回数据块,操作如果是 update,则把变化前数据
修改回去,操作如果是 insert,则根据记录的 rowid 把该记录删除。
2.如果用户 rollback。
则服务器进程会根据数据文件块和 DB BUFFER 中块的头部的事务列表和 SCN 以及回滚段地址找到
回滚段中相应的修改前的副本,并且用这些原值来还原当前数据文件中已修改但未提交的改变。如果有多个
“前映像”,服务器进程会在一个“前映像”的头部找到“前前映像”的回滚段地址,一直找到同一事务下的最早的
一个“前映像”为止。一旦发出了 COMMIT,用户就不能rollback,这使得 COMMIT 后 DBWR 进程还没有
全部完成的后续动作得到了保障。到现在为例一个事务已经结束了。
说明:
TM 锁:
符合 lock 机制的,用于保护对象的定义不被修改。 TX 锁:
这个锁代表一个事务,是行
级锁,用数据块头、数据记录头的一些字段表示,也是符合 lock 机制,有 resource structure、lock
structure、enqueue 算法。

F. SQL清除语句

CREATE SNAPSHOT [schema.]snapshot
[ [PCTFREE integer] [PCTUSED integer]
[INITRANS integer] [MAXTRANS integer]
[TABLESPACE tablespace]
[STORAGE storage_clause]

[ USING INDEX [ PCTFREE integer | TABLESPACE tablespace
| INITTRANS integer | MAXTRANS integer
| STORAGE storage_clause ] ...
| [CLUSTER cluster (column [, column]...)] ]
[ REFRESH [FAST | COMPLETE | FORCE] [START WITH date] [NEXT date]]
AS subquery

schema
is the schema to contain the snapshot. If you omit schema, Oracle

creates the snapshot in your schema.

snapshot
is the name of the snapshot to be created.

Oracle chooses names for the table, views, and index used to
maintain the snapshot by prefixing the snapshot name. To limit
these names to 30 bytes and allow them to contain the entire
snapshot name, Oracle Corporation recommends that you limit your
snapshot names to 23 bytes.

PCTFREE
PCTUSED
INITRANS
MAXTRANS
establishes values for these parameters for the internal table
Oracle uses to maintain the snapshot's data.

TABLESPACE
specifies the tablespace in which the snapshot is to be created. If
you omit this option, Oracle creates the snapshot in the default
tablespace of the owner of the snapshot's schema.

STORAGE
establishes storage characteristics for the table Oracle uses to

maintain the snapshot's data.

USING INDEX
specifies the storage characteristics for the index on a simple
snapshot. If the USING INDEX clause not specified, the index is
create with the same tablespace and storage parameters as the
snapshot.

CLUSTER
creates the snapshot as part of the specified cluster. Since a
clustered snapshot uses the cluster's space allocation, do not use

the PCTFREE, PCTUSED, INITRANS, or MAXTRANS parameters, the
TABLESPACE option, or the STORAGE clause in conjunction with the
CLUSTER option.

REFRESH
specifies how and when Oracle automatically refreshes the snapshot:
FAST
specifies a fast refresh, or a refresh using only the
updated data stored in the snapshot log associated
with the master table.

COMPLETE
specifies a complete refresh, or a refresh that re-
executes the snapshot's query.
FORCE
specifies a fast refresh if one is possible or
complete refresh if a fast refresh is not possible.
Oracle decides whether a fast refresh is possible at
refresh time.

If you omit the FAST, COMPLETE, and FORCE options,
Oracle uses FORCE by default.
START WITH
specifies a date expression for the first automatic
refresh time.
NEXT
specifies a date expression for calculating the
interval between automatic refreshes.

Both the START WITH and NEXT values must evaluate to a time in the

future. If you omit the START WITH value, Oracle determines the
first automatic refresh time by evaluating the NEXT expression when
you create the snapshot. If you specify a START WITH value but omit
the NEXT value, Oracle refreshes the snapshot only once. If you
omit both the START WITH and NEXT values or if you omit the REFRESH
clause entirely, Oracle does not automatically refresh the snapshot.

AS subquery
specifies the snapshot query. When you create the snapshot, Oracle
executes this query and places the results in the snapshot. The
select list can contain up to 253 expressions. A snapshot query is
subject to the same restrictions as a view query.

PREREQUISITES:

To create a snapshot in your own schema, you must have CREATE
SNAPSHOT system privilege. To create a snapshot in another user's

schema, you must have CREATE ANY SNAPSHOT system privilege.

Before a snapshot can be created, the user SYS must run the SQL
script DBMSSNAP.SQL on both the database to contain the snapshot and
the database(s) containing the tables and views of the snapshot's
query. This script creates the package SNAPSHOT which contains both
public and private stored proceres used for refreshing the
snapshot and purging the snapshot log. The exact name and location

of this script may vary depending on your operating system.

When you create a snapshot, Oracle creates a table, two views, and
an index in the schema of the snapshot. Oracle uses these objects
to maintain the snapshot's data. You must have the privileges
necessary to create these objects. For information on these
privileges, see the CREATE TABLE, CREATE VIEW, and CREATE INDEX

commands.

The owner of the schema containing the snapshot must have either
space quota on the tablespace to contain the snapshot or UNLIMITED
TABLESPACE system privilege. Also, both you (the creator) and the
owner must also have the privileges necessary to issue the
snapshot's query.

To create a snapshot, you must be using Oracle with the proceral
option. To create a snapshot on a remote table or view, you must

also be using the distributed option.

G. mysql force index 简单使用

explain sql语句 会返回mysql查询优化器对将要执行的sql的执行计划(不是真的执行，只是给出执行计划)
结果中的possible_keys给出可能使用的索引，
mysql会选择它认为最合适的索引，有时候mysql认为的最优的索引并不是实际上真的的最快的索引
此时可以用force index人为指定索引
force index 跟着表明后面，用于强制使用指定的索引名(key)

H. SQL 语句执行感觉很慢，怎么回事

到这个数量级的全部更新，肯定会很慢。
第一。你的记录不一定在同一个partition，
第二。不明白为什么那么多人建议你建索引，你建的索引越多，你的更新速度越慢，因为你更新记录的同时，还有更新索引。
第三。你必须知道更新速度慢的瓶颈在哪里。是读写太多，还是内存不够，还是CUP不够快，然后对症下药。

下面介绍两个简单的办法，也许有效：
第一：
把这个100W行的表纵向劈成两个，用外键关系连接，一个装小的，经常改变的数据比如ID,外键，状态值，时间等，另一个装大的，不经常改变的数据，比如很长的字符串，xml，text 等。
这样更新时操作小的这个表，可以大大节约内存和CPU 开销，降低磁盘操作。
坏处就是查询时会慢些。
第二：
把这100W行横向切成很多个表，比如每个月的记录装在一个表里，这样每个表的记录数可能只有几万，查询，更新都会快很多。
坏处是查询，更新都不如原来好写。

I. sql中怎么停止正在使用的数据库

请问是什么数据库？？db2的话可以切换至实例用户，使用db2stop
force来停止正在使用的数据库，再使用db2start开启数据库。