仓酷云

标题: MYSQL编程：一条SQL语句变得巨慢的缘故原由及其办理办法... [打印本页]

作者: 深爱那片海 时间: 2015-1-16 22:14
标题: MYSQL编程：一条SQL语句变得巨慢的缘故原由及其办理办法...
表里面的记录数量越多，这个操作的代价就越高。如果作为搜索条件的列上已经创建了索引，MySQL无需扫描任何记录即可迅速得到目标记录所在的位置。<Pstyle="TEXT-INDENT:2em">征象：一条SQL俄然运转的出格慢。<Pstyle="TEXT-INDENT:2em">

selectuidTable.column_value,first_namelast_name,company,job_title,upper(member_level),upper(service_value)from(select*fromtable(selectcast(multiset(selectbfrombbb)asTaaa)fromdual))uidTable,memberwhereuidTable.column_value=member.login_id(+)andmember.site=alibabaandmember.site=test;

复制代码

<Pstyle="TEXT-INDENT:2em"><Pstyle="TEXT-INDENT:2em"><Pstyle="TEXT-INDENT:2em">堕落缘故原由：用户增添了一个前提member.site=test,形成毗连的按次变更了，本来的驱动表是uidTable(最多1024笔记录），如今酿成了member表做驱动(600W条）。以是这条语句变的巨慢。<Pstyle="TEXT-INDENT:2em"><Pstyle="TEXT-INDENT:2em">可是既然是外毗连，为何毗连的按次会改动呢？由于外毗连的毗连按次不是由COST决意的，而是由毗连的前提决意的。发明实行企图以下：<Pstyle="TEXT-INDENT:2em">

-------------------------------------------------------IdOperationNameRowsBytesCost--------------------------------------------------------0SELECTSTATEMENT10187227881551NESTEDLOOPS10187227881552VIEW407269224113COLLECTIONITERATORSUBQUERYFETCH4TABLEACCESSFULLDUAL4072115TABLEACCESSFULLBBB4128726TABLEACCESSBYINDEXROWIDMEMBER1542*7INDEXUNIQUESCANMEMBER_SITE_LID_PK41-------------------------------------------------

复制代码

<Pstyle="TEXT-INDENT:2em"><Pstyle="TEXT-INDENT:2em"><Pstyle="TEXT-INDENT:2em"><Pstyle="TEXT-INDENT:2em">为何基本就没有实行外毗连呢？成绩出在member.site=test这个前提上，由于对外毗连的表加了前提，形成外毗连生效。改成member.site(+)=test后，成绩完全办理。<Pstyle="TEXT-INDENT:2em">

---------------------------------------------------IdOperationNameRowsBytesCost-----------------------------------------------------0SELECTSTATEMENT10187227881551NESTEDLOOPS10187227881552VIEW407269224113COLLECTIONITERATORSUBQUERYFETCH4TABLEACCESSFULLDUAL4072115TABLEACCESSFULLBBB4128726TABLEACCESSBYINDEXROWIDMEMBER1542*7INDEXUNIQUESCANMEMBER_SITE_LID_PK41-----------------------------------------------------------

复制代码

据我的观察，现在有一个趋势，那些经过正式培训的数据库管理员DBA更倾向于选择一个专有关系数据库，例如Oracle。对于一些具有专门数据库管理员的比较大的环境来说，MySQL很难得到宠爱，这时候，关于MySQL是否真的具有良好的可扩展性的争论已经没有意义。

作者: 乐观 时间: 2015-1-19 05:25
大家注意一点。如下面的例子：

作者: 小魔女 时间: 2015-1-19 05:25
总感觉自己还是不会SQL

作者: 仓酷云 时间: 2015-1-27 22:37
发几份SQL课件，以飨阅者

作者: 谁可相欹 时间: 2015-2-5 15:35
作了些试验，发现使用CLR的存储过程或函数在达到一定的阀值的时候，系统性能会呈指数级下滑！这是非常危险的！只使用几个可能没有问题，当一旦大规模使用会造成严重的系统性能问题！

作者: 飘飘悠悠 时间: 2015-2-12 19:19
始终遗憾SQLServer的登陆无法分配CPU/内存占用等指标数。如果你的SQLServer给别人分配了一个只可以读几个表的权限，而这个家伙疯狂的死循环进行连接查询，会给你的系统带来很大的负担。

作者: 只想知道 时间: 2015-3-3 07:47
比如，MicrosoftSQLServer2008的某一个版本可以满足现在的这个业务的需要，而且价格还比Oracle11g要便宜，那么这一产品就是适合的。

作者: 灵魂腐蚀 时间: 2015-3-11 09:59
外键的级联更能扩展可能大部分的同行在设计OLTP系统的时候都不愿意建立外键，都是通过程序来控制父子数据的完整性。

作者: 精灵巫婆 时间: 2015-3-18 07:44
这一点很好的加强了profiler的功能。但是提到profiler提醒大家注意一点。windows2003要安装sp1补丁才能启动profiler。否则点击没有反应。

欢迎光临仓酷云 (http://ckuyun.com/)