[每天进步一点点]关于RAC心跳线：1、心跳线的作用是用来同步实例1和实例2之间数据的；2、故障点转移；3、负载均衡，两个节点同时工作。在RMAN备份时，在实例1分配一个通道，另一个通道分配在实例2上，两个节点同时工作，速度更快。
[每天进步一点点]在RAC中，我们有时会看到一个实例不工作了，那很可能就是心跳线断了。在ORACLE RAC中，如果心跳线断了，这样两边节点的数据就不同步了，这时候只能有一个实例工作，另一个实例必须关闭，以保持数据的唯一性。他们是通过抢表决盘（个数为单数）来决定谁工作的，谁抢到谁工作，另一个就自动关闭了。
[每天进步一点点]对于RAC结构，还是使用业务分割的方式为好，这样某个业务固定地使用某个实例，它访问的数据块就固定地存在于某个实例的内存中，这样实例之间的GC等待事件（Global Cache RAC实例间的内存数据块等待）就会大幅度降低，有助于提供SQL的执行效率。如果RAC结构使用的是负载均衡的模式，这样每个实例都会被各种应用的会话连接，大量的数据块需要在各个实例的内存中被拷贝或者锁定，这样就产生了大量的GC等待事件。
[每天进步一点点]1、对于RAC结构，我们需要分析每一个实例的AWR报告，才能对数据库的性能做出一个客观的评价。2、RAC环境中，动态性能视图以GV$开头，能看到实例1和实例2合在一起的结果，所以有时会看到重复的结果集；3、v$是看单实例自己的；4、OCR是集群注册表，相当于集群的参数文件，如果OCR坏了，集群就起不起来了；5、在单实例中，tnsname.ora里面的service_name就等于DBNAME,但是在RAC里面，可以把instance1和instance2起个名字叫service_name=s1，那么客户端在tnsname.ora里面连接时直接写service_name=s1，就表示连接的是instance1和instance2，从而实现了负载均衡和故障转移。（首先失效，转移到可用节点）；6操作系统叫卷组，oracle叫asm磁盘组；在RAC中，参数文件在instance1和instance2中都有，里面为pfile=引到共享存储；7、oracle 10g用raw和文件系统，oracle 11g用文件系统和asm磁盘组，不支持raw；8、oracle 10g OCR和表决盘不能放共享存储，oracle 11g可以放共享存储。
[每天进步一点点]在一个AWR报告中，其实性能问题可能只是由一个原因引起的，比如说是磁盘I/O能力不够，在AWR报告的各个部分都会向我们呈现出由这个性能问题所引起的属于它覆盖范畴的问题，即一个原因引起很多的表象，当我们从这这个部分一时确定不了问题时，可能从另外一部分的性能数据中就找到了问题出现的原因。这也说明了AWR报告完全不需要顺序地从头读到尾，不论从哪个部分，只要找到了问题的起因，这个AWR报告就算是读完了，完全没有必要每个部分都读一遍，那样只能让自己的思路更加混乱。
[每天进步一点点]关于优化的一点思路：在AWR报告中，最重要的部分是TOP 5 Time Event 部分，这个部分必看，如果这一部分显示前五位等待时间一共也没有等待多长时间（比如第一位的等待时间在1个小时的采集周期中才发生了几分钟的等待），那么我觉得这个AWR报告就没有必要再看下去了，因为看起来系统的状态非常好，几乎没有太长的等待操作，所以不需要做性能上的优化。另外，对于OLTP系统，如果有长时间的等待，那么必须引起注意，找到到原因。但是对于OLAP系统，产生这么长时间的等待也并不一定就是SQL性能上有了问题，因为在OLAP数据库中，本身就运行着一些执行时间非常长的SQL，他们要扫描很多的数据块或者索引块，因此产生等待是合理的，对于这个awr报告来说，我们只能知道有一些SQL执行的时间比较长，至于这些SQL是否真的还有优化的余地，我们需要将SQL语句找到，通过查看他们的执行计划（如sql_trace或10046事件或set autot trace exp stat）,结合SQL中引用的表的分析情况，来断定他的执行计划是否是最优的。如果经过判定这些SQL的执行计划都是最优的，那么这个等待的时间在数据库层面是合理的。如果这个等待时间用户依然无法忍受，那就需要从业务级别来做修改了，比如重写SQL，重新规划数据库等。
[每天进步一点点]在oracle RAC中，重要的核心技术是缓存融合。缓存融合是指把两个机器实例的内存当做一个内存来管理。我们知道，在oracle 单实例中，SGA里有一个列表，它对应着buffer cache有哪些脏数据块，如果客户端发出一条SQL语句，但buffer cache里面没有该对应的脏数据块，那么DB就需要到磁盘中读取数据文件来查找该数据块。那么在RAC中是怎么处理的呢？在RAC中，通过心跳线，两个机器的SGA的脏数据块列表都更新，互相同步对方的脏数据块列表，这样，实例1的脏数据块列表就有实例2的脏数据块信息，假如我在实例1上做了一条update，但是脏数据块在实例2上，那么就把实例2的脏数据块同步到实例1上，这样实例1就不用在去磁盘寻找数据块了，减少了磁盘I/O，这就是RAC的缓存融合技术。对于这项技术，据了解，其他任何一个数据库都没有该技术，可以说也是区别于其他数据库的一项重要技术。
[每日一得]对于DG,STANDBY_FILE_MANAGEMENT 用来控制是否自动将 Primary数据库增加表空间或数据文件的改动，传播到物理 Standby 数据库。AUTO自动，MANUAL手动，默认是手动。如果 Primary 数据库重命名了一个或多个数据文件，该项修改并不会自动传播到 Standby 数据库，只能手工操作。DG原来也不智能。
著名的Oracle技术专家Tom Kyte在他的论坛（asktom.oracle.com)里曾经就STATSPACK说过这样一句话：“没人教过我怎么看statspack报告，我自己也没有学过，但我拿过一份statspack的报告，就可以很容易地看懂它，因为我已经掌握了这些知识，我知道Oracle是如何工作的”。
[每天进步一点点]a、ASH报告是AWR报告的一部分，它侧重于当前数据中活动会话的信息分析，当我们使用$ORACLE_HOME/rdbms/admin/ashrpt.sql脚本生成了一个ASH报告后，对报告进行分析，发现一些相关的性能问题，比如我们发现某个会话的活动非常频繁，或者某个程序可能有性能问题，这时候就可以使用ashrpti.sql脚本来特别针对这些需要分析的对象生成ASH性能分析报告，这样就可以将分析的范围缩小很多，更有利于对问题的定位。
b、在AWR报告中，我们需要客观地对待这些性能指标，不要觉得有些地方稍微有些性能问题，就把问题扩大化，只要用户能够忍系统的性能，就没有理由去主动地优化它，毕竟系统的稳定性是第一位的。
c、AWR和ASH报告的使用场景：当我们需要对数据库系统做整体性能评估时，需要分析AWR性能报告；当我们需要对一些活动的会话或者历史的会话做分析时，使用ASH更加方便，这样可以排除很多不需要的信息干扰，更容易定位到问题所在。
CBO模式的选择：对于一个OLAP系统，数据库上运行着的基本都是报表作业，执行的基本是聚合类SQL操作，比如group by，这时候CBO设置成all_rows是恰当的。但如果这个OLAP系统上面设置成all_rows模式后，该数据库还运行着一些用户分页查询的业务，那么用户一般会抱怨查询慢，针对这种情况，开发人员可以在开发阶段针对分页操作的SQL通过Hint的方式将优化模式转为first_rows，这样就会大大提高数据的处理速度，比如/*+ first_rows(10) */
关于表分区的优化：1、当查询的范围正好落在某个分区的时候，这时候分区的效率自然是高于没有分区的；2、但当查询的范围跨越几个分区时，这时候分区可能不是最优的。比如我们把查询的范围扩大到分区表的13个分区，让CBO使用index_ffs的方式扫描，我们创建另一张非分区表，表结构和上述分区表一样，并且让CBO强制使用index_ffs的方式访问非分区表上的全局索引，结果发现，使用分区索引比全局索引慢很多。为什么呢，分区索引之所以扫描了更多的数据块，是因为分区索引在做index_ffs时只能在本地索引上进行，如果涉及其他的分区，还要按照访问索引的方式去访问其他索引，比如先找到分区索引的根数据块，再找到最左边的叶块，然后执行index_ffs操作，这样，查询跨过的分区越多，这种额外代价就越大；而在这种情况下，全局索引只需要定位到一个叶块，然后执行一次index_ffs就能扫描所有的索引叶块，这样，全局索引的性能就好于分区索引^_^。
当Golden Gate关闭时，还能通过info eorakk, showch看到recovery checkpoint 中scn的信息，说明recovery checkpoint中的scn信息是写在磁盘checkpoint文件上的。ls -lSr，文件按照从小到大的顺序排序；ls -ltr按时间排序；归档日志是联机日志文件的拷贝;
对于热块，可能是数据块，也可能是回滚段块。对于数据块来讲，通常是数据块上的数据分布不均匀导致，如果是索引的数据块，可以通过创建反向索引来达到重新分布数据的目的；对于回滚段数据块，可以适当多增加几个回滚段来避免这种争用。
1、在开发阶段，可以通过模拟一些实际的数量来估算索引和表数据的一个比例，然后做出索引所占空间和表所占空间的比例：
select avg_row_len from user_tables where table_name='T';
AVG_ROW_LEN
-----------
93
表的容量：93*N（记录数）
select segMENt_name,SEGMENT_type,bytes,owner from dba_segments where segment_name in ('T','IND_T_OBJECT_ID');
2、系统如果平时运行正常，突然停止不动了，多半是被阻止blocked住了，我通常做的第一个动作就是先看v$lock这张视图：
QL> select sid,type,id1,id2,lmode,request,block from v$lock where sid in (143,156);
SID TY ID1 ID2 LMODE REQUEST BLOCK
---------- -- ---------- ---------- ---------- ---------- ----------
156 TX 458761 525 0 6 0
143 TM 53345 0 3 0 0
156 TM 53345 0 3 0 0
143 TX 458761 525 6 0 1
上图中，产生了TX事务锁（TX叫行锁是误导）的阻塞
TX，oracle数据库并不会对某个表加上锁或者某几行加上锁，锁是以一个数据块的属性存在的。每个数据块本身就存储着自己数据块中数据的信息，这个地方叫ITL（interested transaction list），凡是在这个数据块上有活动的事务，他的信息就会记录在这里面供后续操作查询，以保证事务的一致性。
TX锁应该是一个事务锁（称它为行级锁是误导），无论这个事务做了多少操作，都只是这一个事务锁，和他所操作的数据多少没有关系。
什么时候会产生TX事务锁呢？1、对数据进行update修改的时候；2、只要需要维护事务一致性的时候，就会用到TX事务锁，比如通过DBLINK在几个数据库之间处理数据时，就需要TX事务锁俩维护事务的一致性。
上图中，TM是表级的共享锁，就是说每个用户都可以以共享的方式持有它。TM锁也并不是加在表上的一个锁，他会在表的级别上产生影响，比如它不允许其他用户对表锁DDL操作。
再重复一遍，oracle中的锁的信息是数据块的一个属性，是物理的，并不是逻辑上属于某个表或者某个行。
可以通过v$session视图就可以这两个sid的用户登陆信息；
QL> select machine from v$session where sid in (156,146);
MACHINE
----------------------------------------------------------------
localhost.localdomain
localhost.localdomain
上述过程之能是一个故障定位，不能说是一个性能优化。
##################################
SQL> select sid,type,id1,id2,lmode,request,block from v$lock where sid in (143,156);
SID TY ID1 ID2 LMODE REQUEST BLOCK
---------- -- ---------- ---------- ---------- ---------- ----------
143 TM 53347 0 3 0 0
143 TM 53348 0 3 0 0
143 TX 458775 525 6 0 0
SQL> select object_name,subobject_name from dba_objects where object_id in (53347,53348);
OBJECT_NAME SUBOBJECT_NAME
--------------- ------------------------------
T
T P1
通过上图中，可以看出，对于TM，id1列其实就是dba_object里面的object_id，可以是一个表，也可以是一个分区，此时的ID2一般为0。
而在TX事务锁中，ID1和ID2这两个字段构成了这个事务在回滚段中的位置。这有什么作用呢，他的用途是，当其他的操作需要读取这个数据块时，他会发现这个块上要读取的数据上是有活动事务的，因此需要到回滚段中去找它之前的内容的，那么这些内容在回滚段中的什么地方呢，这两个值告诉你。
当你的系统有主键和外键引用关系时，如下三种情况就需要考虑给外键字段创建索引，主键已经默认创建索引了。
1、主键上有频繁的删除操作；2、主键上有频繁的修改操作；3、业务上经常会出现主表和从表做关联查询的情况。
三个简单却很有意义的公式：
① 开会+ 不落实 = 零
② 布置工作 + 不检查 = 零
③ 抓住不落实的事 + 追究不落实的人 = 落实
[每天进步一点点]在RAC中，我们有时会看到一个实例不工作了，那很可能就是心跳线断了。在ORACLE RAC中，如果心跳线断了，这样两边节点的数据就不同步了，这时候只能有一个实例工作，另一个实例必须关闭，以保持数据的唯一性。他们是通过抢表决盘（个数为单数）来决定谁工作的，谁抢到谁工作，另一个就自动关闭了。
[每天进步一点点]对于RAC结构，还是使用业务分割的方式为好，这样某个业务固定地使用某个实例，它访问的数据块就固定地存在于某个实例的内存中，这样实例之间的GC等待事件（Global Cache RAC实例间的内存数据块等待）就会大幅度降低，有助于提供SQL的执行效率。如果RAC结构使用的是负载均衡的模式，这样每个实例都会被各种应用的会话连接，大量的数据块需要在各个实例的内存中被拷贝或者锁定，这样就产生了大量的GC等待事件。
[每天进步一点点]1、对于RAC结构，我们需要分析每一个实例的AWR报告，才能对数据库的性能做出一个客观的评价。2、RAC环境中，动态性能视图以GV$开头，能看到实例1和实例2合在一起的结果，所以有时会看到重复的结果集；3、v$是看单实例自己的；4、OCR是集群注册表，相当于集群的参数文件，如果OCR坏了，集群就起不起来了；5、在单实例中，tnsname.ora里面的service_name就等于DBNAME,但是在RAC里面，可以把instance1和instance2起个名字叫service_name=s1，那么客户端在tnsname.ora里面连接时直接写service_name=s1，就表示连接的是instance1和instance2，从而实现了负载均衡和故障转移。（首先失效，转移到可用节点）；6操作系统叫卷组，oracle叫asm磁盘组；在RAC中，参数文件在instance1和instance2中都有，里面为pfile=引到共享存储；7、oracle 10g用raw和文件系统，oracle 11g用文件系统和asm磁盘组，不支持raw；8、oracle 10g OCR和表决盘不能放共享存储，oracle 11g可以放共享存储。
[每天进步一点点]在一个AWR报告中，其实性能问题可能只是由一个原因引起的，比如说是磁盘I/O能力不够，在AWR报告的各个部分都会向我们呈现出由这个性能问题所引起的属于它覆盖范畴的问题，即一个原因引起很多的表象，当我们从这这个部分一时确定不了问题时，可能从另外一部分的性能数据中就找到了问题出现的原因。这也说明了AWR报告完全不需要顺序地从头读到尾，不论从哪个部分，只要找到了问题的起因，这个AWR报告就算是读完了，完全没有必要每个部分都读一遍，那样只能让自己的思路更加混乱。
[每天进步一点点]关于优化的一点思路：在AWR报告中，最重要的部分是TOP 5 Time Event 部分，这个部分必看，如果这一部分显示前五位等待时间一共也没有等待多长时间（比如第一位的等待时间在1个小时的采集周期中才发生了几分钟的等待），那么我觉得这个AWR报告就没有必要再看下去了，因为看起来系统的状态非常好，几乎没有太长的等待操作，所以不需要做性能上的优化。另外，对于OLTP系统，如果有长时间的等待，那么必须引起注意，找到到原因。但是对于OLAP系统，产生这么长时间的等待也并不一定就是SQL性能上有了问题，因为在OLAP数据库中，本身就运行着一些执行时间非常长的SQL，他们要扫描很多的数据块或者索引块，因此产生等待是合理的，对于这个awr报告来说，我们只能知道有一些SQL执行的时间比较长，至于这些SQL是否真的还有优化的余地，我们需要将SQL语句找到，通过查看他们的执行计划（如sql_trace或10046事件或set autot trace exp stat）,结合SQL中引用的表的分析情况，来断定他的执行计划是否是最优的。如果经过判定这些SQL的执行计划都是最优的，那么这个等待的时间在数据库层面是合理的。如果这个等待时间用户依然无法忍受，那就需要从业务级别来做修改了，比如重写SQL，重新规划数据库等。
[每天进步一点点]在oracle RAC中，重要的核心技术是缓存融合。缓存融合是指把两个机器实例的内存当做一个内存来管理。我们知道，在oracle 单实例中，SGA里有一个列表，它对应着buffer cache有哪些脏数据块，如果客户端发出一条SQL语句，但buffer cache里面没有该对应的脏数据块，那么DB就需要到磁盘中读取数据文件来查找该数据块。那么在RAC中是怎么处理的呢？在RAC中，通过心跳线，两个机器的SGA的脏数据块列表都更新，互相同步对方的脏数据块列表，这样，实例1的脏数据块列表就有实例2的脏数据块信息，假如我在实例1上做了一条update，但是脏数据块在实例2上，那么就把实例2的脏数据块同步到实例1上，这样实例1就不用在去磁盘寻找数据块了，减少了磁盘I/O，这就是RAC的缓存融合技术。对于这项技术，据了解，其他任何一个数据库都没有该技术，可以说也是区别于其他数据库的一项重要技术。
[每日一得]对于DG,STANDBY_FILE_MANAGEMENT 用来控制是否自动将 Primary数据库增加表空间或数据文件的改动，传播到物理 Standby 数据库。AUTO自动，MANUAL手动，默认是手动。如果 Primary 数据库重命名了一个或多个数据文件，该项修改并不会自动传播到 Standby 数据库，只能手工操作。DG原来也不智能。
著名的Oracle技术专家Tom Kyte在他的论坛（asktom.oracle.com)里曾经就STATSPACK说过这样一句话：“没人教过我怎么看statspack报告，我自己也没有学过，但我拿过一份statspack的报告，就可以很容易地看懂它，因为我已经掌握了这些知识，我知道Oracle是如何工作的”。
[每天进步一点点]a、ASH报告是AWR报告的一部分，它侧重于当前数据中活动会话的信息分析，当我们使用$ORACLE_HOME/rdbms/admin/ashrpt.sql脚本生成了一个ASH报告后，对报告进行分析，发现一些相关的性能问题，比如我们发现某个会话的活动非常频繁，或者某个程序可能有性能问题，这时候就可以使用ashrpti.sql脚本来特别针对这些需要分析的对象生成ASH性能分析报告，这样就可以将分析的范围缩小很多，更有利于对问题的定位。
b、在AWR报告中，我们需要客观地对待这些性能指标，不要觉得有些地方稍微有些性能问题，就把问题扩大化，只要用户能够忍系统的性能，就没有理由去主动地优化它，毕竟系统的稳定性是第一位的。
c、AWR和ASH报告的使用场景：当我们需要对数据库系统做整体性能评估时，需要分析AWR性能报告；当我们需要对一些活动的会话或者历史的会话做分析时，使用ASH更加方便，这样可以排除很多不需要的信息干扰，更容易定位到问题所在。
CBO模式的选择：对于一个OLAP系统，数据库上运行着的基本都是报表作业，执行的基本是聚合类SQL操作，比如group by，这时候CBO设置成all_rows是恰当的。但如果这个OLAP系统上面设置成all_rows模式后，该数据库还运行着一些用户分页查询的业务，那么用户一般会抱怨查询慢，针对这种情况，开发人员可以在开发阶段针对分页操作的SQL通过Hint的方式将优化模式转为first_rows，这样就会大大提高数据的处理速度，比如/*+ first_rows(10) */
关于表分区的优化：1、当查询的范围正好落在某个分区的时候，这时候分区的效率自然是高于没有分区的；2、但当查询的范围跨越几个分区时，这时候分区可能不是最优的。比如我们把查询的范围扩大到分区表的13个分区，让CBO使用index_ffs的方式扫描，我们创建另一张非分区表，表结构和上述分区表一样，并且让CBO强制使用index_ffs的方式访问非分区表上的全局索引，结果发现，使用分区索引比全局索引慢很多。为什么呢，分区索引之所以扫描了更多的数据块，是因为分区索引在做index_ffs时只能在本地索引上进行，如果涉及其他的分区，还要按照访问索引的方式去访问其他索引，比如先找到分区索引的根数据块，再找到最左边的叶块，然后执行index_ffs操作，这样，查询跨过的分区越多，这种额外代价就越大；而在这种情况下，全局索引只需要定位到一个叶块，然后执行一次index_ffs就能扫描所有的索引叶块，这样，全局索引的性能就好于分区索引^_^。
当Golden Gate关闭时，还能通过info eorakk, showch看到recovery checkpoint 中scn的信息，说明recovery checkpoint中的scn信息是写在磁盘checkpoint文件上的。ls -lSr，文件按照从小到大的顺序排序；ls -ltr按时间排序；归档日志是联机日志文件的拷贝;
对于热块，可能是数据块，也可能是回滚段块。对于数据块来讲，通常是数据块上的数据分布不均匀导致，如果是索引的数据块，可以通过创建反向索引来达到重新分布数据的目的；对于回滚段数据块，可以适当多增加几个回滚段来避免这种争用。
1、在开发阶段，可以通过模拟一些实际的数量来估算索引和表数据的一个比例，然后做出索引所占空间和表所占空间的比例：
select avg_row_len from user_tables where table_name='T';
AVG_ROW_LEN
-----------
93
表的容量：93*N（记录数）
select segMENt_name,SEGMENT_type,bytes,owner from dba_segments where segment_name in ('T','IND_T_OBJECT_ID');
2、系统如果平时运行正常，突然停止不动了，多半是被阻止blocked住了，我通常做的第一个动作就是先看v$lock这张视图：
QL> select sid,type,id1,id2,lmode,request,block from v$lock where sid in (143,156);
SID TY ID1 ID2 LMODE REQUEST BLOCK
---------- -- ---------- ---------- ---------- ---------- ----------
156 TX 458761 525 0 6 0
143 TM 53345 0 3 0 0
156 TM 53345 0 3 0 0
143 TX 458761 525 6 0 1
上图中，产生了TX事务锁（TX叫行锁是误导）的阻塞
TX，oracle数据库并不会对某个表加上锁或者某几行加上锁，锁是以一个数据块的属性存在的。每个数据块本身就存储着自己数据块中数据的信息，这个地方叫ITL（interested transaction list），凡是在这个数据块上有活动的事务，他的信息就会记录在这里面供后续操作查询，以保证事务的一致性。
TX锁应该是一个事务锁（称它为行级锁是误导），无论这个事务做了多少操作，都只是这一个事务锁，和他所操作的数据多少没有关系。
什么时候会产生TX事务锁呢？1、对数据进行update修改的时候；2、只要需要维护事务一致性的时候，就会用到TX事务锁，比如通过DBLINK在几个数据库之间处理数据时，就需要TX事务锁俩维护事务的一致性。
上图中，TM是表级的共享锁，就是说每个用户都可以以共享的方式持有它。TM锁也并不是加在表上的一个锁，他会在表的级别上产生影响，比如它不允许其他用户对表锁DDL操作。
再重复一遍，oracle中的锁的信息是数据块的一个属性，是物理的，并不是逻辑上属于某个表或者某个行。
可以通过v$session视图就可以这两个sid的用户登陆信息；
QL> select machine from v$session where sid in (156,146);
MACHINE
----------------------------------------------------------------
localhost.localdomain
localhost.localdomain
上述过程之能是一个故障定位，不能说是一个性能优化。
##################################
SQL> select sid,type,id1,id2,lmode,request,block from v$lock where sid in (143,156);
SID TY ID1 ID2 LMODE REQUEST BLOCK
---------- -- ---------- ---------- ---------- ---------- ----------
143 TM 53347 0 3 0 0
143 TM 53348 0 3 0 0
143 TX 458775 525 6 0 0
SQL> select object_name,subobject_name from dba_objects where object_id in (53347,53348);
OBJECT_NAME SUBOBJECT_NAME
--------------- ------------------------------
T
T P1
通过上图中，可以看出，对于TM，id1列其实就是dba_object里面的object_id，可以是一个表，也可以是一个分区，此时的ID2一般为0。
而在TX事务锁中，ID1和ID2这两个字段构成了这个事务在回滚段中的位置。这有什么作用呢，他的用途是，当其他的操作需要读取这个数据块时，他会发现这个块上要读取的数据上是有活动事务的，因此需要到回滚段中去找它之前的内容的，那么这些内容在回滚段中的什么地方呢，这两个值告诉你。
当你的系统有主键和外键引用关系时，如下三种情况就需要考虑给外键字段创建索引，主键已经默认创建索引了。
1、主键上有频繁的删除操作；2、主键上有频繁的修改操作；3、业务上经常会出现主表和从表做关联查询的情况。
三个简单却很有意义的公式：
① 开会+ 不落实 = 零
② 布置工作 + 不检查 = 零
③ 抓住不落实的事 + 追究不落实的人 = 落实
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/28916011/viewspace-1663704/ ，如需转载，请注明出处，否则将追究法律责任。
下一篇：
关于connet by的学习
请登录后发表评论
登录
全部评论
