一个表有一百八十多个字段，这个对系统有无影响？

Cocal

原帖由 TOADLover 于 2009-8-11 09:01 发表
会大幅度降低表数据块的访问需求---->指的是插入、更新还是查询？我觉得这三种操作对数据块的访问应该是不同的吧，我不确定，因为我确实对这个不是很了解。。

索引对所有带条件、排序、分组字句的SQL都会带来性能改善，如果没有索引，只有做全表扫描去获取信息，一是要产生I/O，第二是由于没排序，运算量大。
除了索引对数据块访问的影响，直接影响数据块访问需求的因素是sql涉及数据集的大小。

如果你执行"select * from xx"，并要求全部返回客户端，或者“update xx set x='y'”，不管有没有索引，客观上都需要遍历所有数据块，对吧？
但实际应用中，绝大多数对数据库的访问是带where字句的，涉及的数据集越小，数据总量越大，索引带来的好处就越明显。

索引合不合理，很容易产生数十倍性能差别。所以说，弄好索引比微调存储要来的紧要。（一家之言吧，实际情况复杂的多，和你的应用类型，业务流量等关系很大。）

[ 本帖最后由 Cocal 于 2009-8-12 10:13 编辑 ]

Cocal

原帖由 TOADLover 于 2009-8-11 09:05 发表
我想应该关键是pctused和pctfree的问题，索引当然也很重要，是查询时的优化了。
----------------------------------------------------------------------------------------
谁知道怎么优化pctused和pctfre ...

这两个参数其实已经很细微了，要花很多时间根据系统实际情况去调，并且可能不同的DBA的结论又不一样，个人觉得已经属于比较“艺术”的参数了。
是不是关键，得仔细看，只是想应该是啥明显是不够的，呵呵
找到两个关于行链接和行迁移的检测和防止的文章供参考：
http://www.cnblogs.com/afant/archive/2008/04/19/1161648.html
http://www.linuxdiyf.com/blog/?8 ... ce_itemid_2261.html

针对的你情况，先得弄清楚，180列，和他的存储没有必然联系，180个数值列占用的空间可能比不上一个blob（180个数值列的表一点都不大），对吧？
你的数据一行占用多少存储？可以先估个大概（变长属性可能要参考实际数据情况）。

然后是数据的更新频度？或者是否经常删？实际上大多数应用数据改的是不多的，例如一张记录实验数据的表，一旦形成就不会再修改，一般也不删除，那么pctfree设的太高，只能造成空间利用率下降，而pctused怎么设对性能都没有影响。

行迁移和行链接造成性影响的状况上述链接给出了检测方法。我想大概会发生在单行数据超过db_block_size，或者单行尺寸接近db_block_size，并存在大量变长修改、删除、增加操作的时候。
具体的解决方法的确的确得看实际情况，也许调整数据库参数是合理的，也许拆表是合理的。

总之，需要考虑的东西很多，经验很重要，要获得经验，首先得有环境，只看资料或者纸上谈兵没多大帮助（这也是高手不多的原因）。

*LZ的系统有性能问题吗？如果没有，往下没法聊了。如果现在没有，预计以后有，那么密切监视，发现具体问题尽快解决。

[ 本帖最后由 Cocal 于 2009-8-12 12:44 编辑 ]

TOADLover

原帖由 Cocal 于 2009-8-12 09:35 发表


索引对所有带条件、排序、分组字句的SQL都会带来性能改善，如果没有索引，只有做全表扫描去获取信息，一是要产生I/O，第二是由于没排序，运算量大。
除了索引对数据块访问的影响，直接影响数据块访问需求的 ...

----------------------------------------------
：）
我钻牛角尖:
-------------
如果你执行"select * from xx"，并要求全部返回客户端，或者“update xx set x='y'”，不管有没有索引，客观上都需要遍历所有数据块，对吧？
但实际应用中，绝大多数对数据库的访问是带where字句的，涉及的数据集越小，数据总量越大，索引带来的好处就越明显。
--------------
这两种SQL语句的机会极少的。 我使用时也会用"select * from xx where rownum<10"
--------------
根据应用层的需要，比如应用程序经常用到"select * from xx where aa< 10 and bb > 25" 那我就会在aa字段和bb字段上建索引了，一般都是类似这种。
你觉得这么做怎么样？

TOADLover

原帖由 Cocal 于 2009-8-12 10:00 发表


这两个参数其实已经很细微了，要花很多时间根据系统实际情况去调，并且可能不同的DBA的结论又不一样，个人觉得已经属于比较“艺术”的参数了。
是不是关键，得仔细看，只是想应该是啥明显是不够的，呵呵
...

-------------------------------
针对的你情况，先得弄清楚，180列，和他的存储没有必然联系，180个数值列占用的空间可能比不上一个blob（180个数值列的表一点都不大），对吧？
你的数据一行占用多少存储？可以先估个大概（变长属性可能要参考实际数据情况）。
-------------------------------
对，我的表的字段全是varchar2(20 byte)和number(10)和char(1)，这三种字段，不涉及blob等等。

TOADLover

-----------------
然后是数据的更新频度？或者是否经常删？实际上大多数应用数据改的是不多的，例如一张记录实验数据的表，一旦形成就不会再修改，一般也不删除，那么pctfree设的太高，只能造成空间利用率下降，而pctused怎么设对性能都没有影响。
-----------------
几乎不会删，更新会比较频繁，做生产控制的。

TOADLover

----------------------
行迁移和行链接造成性能影响的状况上述链接给出了检测方法。我想大概会发生在
单行数据超过db_block_size，-->指单行数据所占物理空间的大小？
或者对单张行尺寸接近db_block_size，并存在大量变长修改、删除、增加操作的时候。
-----------
什么叫"对单张行尺寸接近db_block_size"？什么叫"大量变长修改、删除、增加操作"？
-----------
具体的解决方法的确的确得看实际情况，也许调整数据库参数是合理的，也许拆表是合理的。
----------------------

[ 本帖最后由 TOADLover 于 2009-8-12 10:45 编辑 ]

Cocal

原帖由 TOADLover 于 2009-8-12 10:32 发表

根据应用层的需要，比如应用程序经常用到"select * from xx where aa< 10 and bb > 25" 那我就会在aa字段和bb字段上建索引了，一般都是类似这种。
你觉得这么做怎么样？

我觉得这是基本操作啊，如果不建索引，必须得做全表扫描，把aa<10的rowid和bb>25的rowid找出来，然后再做集合计算（也许实际处理是一次扫描逐行逻辑and，但全表扫描避免不了）。

如果针对aa和bb建了索引，这些索引已经按照内容作好排序，只需要抽取两个索引的子集，再做集合运算就知道结果了，避免了全表扫描。

数据量小看不出影响，数据量越大，返回的结果越少，影响越明显。

* select * from xx where rownum<10不用建索引，可以认为rowid是递增的，自然排序。

vema

这种表是传说中的胖表？
鄙人不才，见过以k计列数的表，而且绝对不是1k。

Cocal

原帖由 TOADLover 于 2009-8-12 10:44 发表
----------------------
行迁移和行链接造成性能影响的状况上述链接给出了检测方法。我想大概会发生在
单行数据超过db_block_size，-->指单行数据所占物理空间的大小？
或者对单张行尺寸接近db_block_size， ...

“或者对单张行尺寸接近db_block_size”，这里有一个笔误，应为“或者单行尺寸接近db_block_size”，修改过了，抱歉。

db_block_size是Oracle的基本处理单位，建议LZ读一些ORACLE 的资料。

“大量变长修改、删除、增加操作”准确的说应该是
“大量涉及ORACLE变长数据类型的修改、删除、增加操作”。

变长数据类型（或叫变长字段类型）在Oracle基础资料里都有，这里也找出来给你看：

http://zhidao.baidu.com/question/64353743.html
http://zzg.javaeye.com/blog/111786

关于不同数据类型实际对存储空间的要求，下面这个贴子里有具体的实验：
Oracle 数据类型及存储方式
http://www.javaeye.com/topic/220760

这里说数据类型的原因是，只有对变长数据的更新，才会对存储产生影响，pctfree和pctused就是为这个准备，如果你更新的定长数据类型，存储结构根本就不需要改变。

如何计算一行数据占用的数据空间，参见这个链接：
Oracle如何精确计算row的大小
http://9host.cn/oracle/200742218395312855.html

==========================
恕在下直言，通过最近两贴，感觉您的基础知识结构直接讨论这个话题会比较吃力。
几乎每个喜欢技术的人都喜欢钻牛角尖，但是几乎每个喜欢技术的人都首先会从Google上寻找疑问的答案。
我不能再这么象喂鸭子一样回答你的问题了，否则会被其他人说我坏了技术论坛的风气。
建议您读读ORACLE的技术资料，有时间的顺便读读那本著名的《提问的智慧》。
抱歉！

[ 本帖最后由 Cocal 于 2009-8-12 13:03 编辑 ]

whtech

这个多字段我们在系统中也用过,检索问题不大,但取值似乎性能相差很大（180和50字段）,jdbc连数据库。