sql文档中心

ORACLE SQL语句优化总结

1）选择最有效率的表名顺序(只在基于规则的优化器中有效)：
ORACLE的解析器按照从右到左的顺序处理from子句中的表名，from子句中写在最后的表(基础表 driving table)将被最先处理，在from子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表。如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其他表所引用的表.
   （2） WHERE子句中的连接顺序．：
ORACLE采用自下而上的顺序解析WHERE子句,根据这个原理,表之间的连接必须写在其他WHERE条件之前, 那些可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾.
   （3） SELECT子句中避免使用 ‘ * ‘：
ORACLE在解析的过程中, 会将'*' 依次转换成所有的列名, 这个工作是通过查询数据字典完成的, 这意味着将耗费更多的时间
   （4）减少访问数据库的次数：
ORACLE在内部执行了许多工作: 解析SQL语句, 估算索引的利用率, 绑定变量 , 读数据块等；
   （5）在SQL*Plus , SQL*Forms和Pro*C中重新设置ARRAYSIZE参数, 可以增加每次数据库访问的检索数据量 ,建议值 ......

数据库中主键和外键
(1)作用
简单描述：
主键是对表的约束，保证数据的唯一性！
外键是建立表于表之间的联系，方便程序的编写！
(2)设计原则
主键和外键是把多个表组织为一个有效的关系数据库的粘合剂。主键和外键的设计对物理数据库的性能和可用性都有着决定性的影响。
必须将数据库模式从理论上的逻辑设计转换为实际的物理设计。而主键和外键的结构是这个设计过程的症结所在。一旦将所设计的数据库用于了生产环境，就很难对这些键进行修改，所以在开发阶段就设计好主键和外键就是非常必要和值得的。
主键：
关系数据库依赖于主键---它是数据库物理模式的基石。主键在物理层面上只有两个用途：
        1. 惟一地标识一行。
        2. 作为一个可以被外键有效引用的对象。
基于以上这两个用途，下面给出了我在设计物理层面的主键时所遵循的一些原则：
        1. 主键应当是对用户没有意义的。如果用户看到了一个表示多对多关系的连接表中的数据，并抱怨它没有什么用处，那就证明它的主键设计地很好。
......

winform下：
         //存储
        private void MemoryImage()
        {
            string sql = "";
            //string conn = "Provider=SQLNCLI;Data Source=192.168.0.9,1433;Database=WebDown;UID=sa;PWD=111122;";
            Stream ms;
            byte[] picbyte;
            OpenFileDialog ofdSelectPic = new OpenFileDialog();
            if (ofdSelectPic.ShowDialog() == DialogResult.OK)
            {
             &nbs ......

CREATE DATABASE
创建一个新数据库及存储该数据库的文件，或从先前创建的数据库的文件中附加数据库。
说明有关与 DISK INIT 向后兼容性的更多信息，请参见"Microsoft® SQL Server™ 向后兼容性详细信息"中的设备（级别 3）。
语法
CREATE DATABASE database_name
[ ON
[ < filespec > [ ,...n ] ]
[ , < filegroup > [ ,...n ] ]
]
[ LOG ON { < filespec > [ ,...n ] } ]
[ COLLATE collation_name ]
[ FOR LOAD | FOR ATTACH ]
< filespec > ::=
[ PRIMARY ]
( [ NAME = logical_file_name , ]
FILENAME = 'os_file_name'
[ , SIZE = size ]
[ , MAXSIZE = { max_size | UNLIMITED } ]
[ , FILEGROWTH = growth_increment ] ) [ ,...n ]
< filegroup > ::=
FILEGROUP filegroup_name < filespec > [ ,...n ]
参数
database_name
新数据库的名称。数据库名称在服务器中必须唯一，并且符合标识符的规则。database_name 最多可以包含 128 个字符，除非没有为日志指定逻辑名。如果没有指定日志文件的逻辑名，则 Microsoft® SQL Server™ 会通过向 database_name ......

刚刚在inthirties老大的博客里看到这篇文章，写的不错，正好自己最近在学习PL/SQL，转过来学习学习。
==================================================================================
bulk collect是可以看做是一种批获取的方式，在我们的plsql的代码段里经常作为into的扩展来使用。对于select id into v from .... 是一个常用的用法。不过这里只能是返回单条记录的时候，才能使用，如果是有多条记录我们就不能用这样的方式，而是使用fetch和循环的方式，不仅使用麻烦，而且性能也底下，这时我们的bulk collect隆重登场了，解决我们的问题。
通过bulk collect可以把我们的查询结果一次性地加载到我们的嵌入表中。这样我们不需要很麻烦的用游标的循环一条一条的去fetch叻，可想而知，这样不仅操作方便，也可以获得相当不错的程序性能。我们可以在select into, fetch into, returning into的句子中使用。下面我们通过对以上各个例子来进行演示来看看他们的用法
先来看看我们的测试表和数据
SQL> desc test;
Name Null? Type
----------------------------------------- -------- ----------------------------
ZC_CODE VARCHAR2(20)
MONEY NUMBER(35) ......

说句大废话，那就是“合理的平衡各种资源的使用,内存,cpu,io 等等”。这也是很有道理的，但是实际就不好做了，如何平衡呢？
具体点的么，通过比较，应该是响应时间做为主要的评判因素了。但是可能由于一些不确定的因素，可能会出现：这次跑的快，不等于下次也跑的快了。
那就要根据表的数据量的变化，确定一个比较合理的执行计划了，主要还是要降低逻辑读为调优的目标，其实物理读意义不大，一个sql语句第一次执行物理读肯定是很大的，到了第2次物理读也许就很小了。
某高人说：
在数据库整体上来讲，是要降低物理读
而对于单条 sql 来讲，是以逻辑读的降低为标准的
道理很简单，对于单条sql来说，如果反复运行，物理读决定于 data buffer 的大小，第一次运行和第二次运行也是不一样的。
但比较稳定的是逻辑读。如果以物理读为标准，那难道物理读为0的sql就是好sql 了？如果sql的逻辑读都良好，那数据库整体的物理读降下来也是很自然的事情
高人又说：
临时段是不会生产redo 的
buffer gets 就可以理解为对 buffer cache 中 buffer 的访问 buffer*次，也可以看做访问的 buffer数量，当然可能存在着一个buffer被访问多次的情况
至于 buffer gets ......

ORACLE SQL语句优化总结

ORACLE SQL语句优化总结

SQL SERVER中主键和外键

C# sql 实现图片批量储存读取

C# sql 实现图片批量储存读取

动态创建Sql Server数据库相关（全）

ORACLE PL/SQL开发

ORACLE PL/SQL开发

关于SQL优化