易栈网-膘叔（Neatstudio.COM）

易栈网-膘叔

有点意思：QQ 我的好友想到的信息架构

Navicat 软件及其注册码

2001年以来的数据库技术领域回顾

语言包？

联合索引的经典例子

有点意思：QQ 我的好友想到的信息架构

Navicat 软件及其注册码

2001年以来的数据库技术领域回顾

语言包？

联合索引的经典例子

日志分类

热门标签

日志归档

搜索文章

最新评论

博客信息

友情链接

2001

2002

2003

2004

2005

2006

2007

2008

2009

不是总结的总结

2001

2002

2003

2004

2005

2006

2007

2008

2009

不是总结的总结

浏览模式: 标准 | 列表Tag:数据库

Submitted by gouki on 2010, April 19, 9:28 AM

这篇文章有点意思，不过我更多的想的不是他所说的这种分类，一般来说，在电子商务里面这方面，这方面其实是最难界定的。产品A既可能属于B分类，也可能是属于C分类。但是在促销的时候，B分类产品不打折，C分类可以打折，这时你把A产品怎么处理？打折还是不打折？

QQ好友列表：

＋太原（9/39）
＋运城老乡（9/49）
＋西安（9）
＋学校（19）

问题：
QQ好友上新建了一个女孩组和一个西安组，上面的整理方式，发现经常弄错，比如“XX“同学，是我女友介绍认识的，我将她顺便放在太原组里面，后来知道她不在太原，山西运城人士，当我和她聊天时候，连我自己都很吃惊经常问，太原的一些情况，很是影响人家心情，搞的自己也很尴尬。
很长一段时间，渐渐习惯这种分类，突然间觉得这样的分类很不科学，很明显，这涉及SNS的经典问题，以及信息架构的经典问题：如何做一个有效分类？

我的需求：
1.      新添加一个朋友的时候固定存放
2.      常联系的人立马可以找到
3.      和我趣味相投的统统放在一起，玩到一起的，闲来没事可以出去一起疯狂的
4.      能够表达出我的职业规划，定位明确，可以清楚的阐述我的社会活动能力与人际关系

详细说明：

要做到：
1. 清楚地表现好友信息：一看这个分类，就知道这一类型的人是干什么的，和他们应该在那些方面可以顺利沟通清楚问题。
2. 层次结构清晰：一看这个分类，就知道什么人在这个分类下面，分类下面涉及到什么朋友

不应该是：
1.      这个分类给人一种距离感，陌生
2.      我想找的是分类A，但你却出现在分类B中？NND
3.      这个分类做出来不能让我自己都犯晕！

问题的表象是如何找到一个合理的好友分类方式，深入问题的本质，其实是不满足我的需求，而QQ体现的核心是我的二字，因此人际关系、社会活动能力、我的职业规划就是该信息架构问题的关键！这样就有了看似简单但能立刻解决问题的分类方式：

QQ好友列表：

＋熟人（9/19）
＋一家人（9/19）
＋一帮子（9/14）
＋光屁股长大（9/100）
+刚认识（2/10）
+xxx公司
+xxx公司

一切就这么简单，采用这个分类以后，立即心旷神怡！

--EOF--

原文来自：http://www.cnblogs.com/u_xiaomo/archive/2010/04/18/1714953.html

不过话说回来，抛开电子商务的因素，wordpress的分类设计的就是挺不错的。一篇文章在你迷惘的时候，可以放到多个分类里，分类又只是相当于一个标签。这样的设计让使用者也很爽。只是开发的时候累一点，SQL的性能差一点点而己。

Tags: wordpress, qq, 架构, 数据库

DataBase | 评论:2 | 阅读:24999

Submitted by gouki on 2009, August 26, 9:33 AM

以下内容本人不负责，来自于Tdweb的博客：

Navicat 软件及其注册码

Navicat 是一个强大的MySQL数据库管理和开发工具。Navicat为专业开发者提供了一套强大的足够尖端的工具，但它对于新用户仍然是易于学习。 Navicat,使用了极好的图形用户界面（GUI），可以让你用一种安全和更为容易的方式快速和容易地创建、组织、存取和共享信息。用户可完全控制 MySQL 数据库和显示不同的管理资料，包括一个多功能的图形化管理用户和访问权限的管理工具，方便将数据从一个数据库移转到另一个数据库中（Local to Remote、Remote to Remote、Remote to Local），进行档案备份。 Navicat 支援 Unicode，以及本地或遥距 MySQL 伺服器多连线，用户可浏览数据库、建立和删除数据库、编辑数据、建立或执行 SQL queries、管理用户权限（安全设定）、将数据库备份/复原、汇入/汇出数据（支援 CSV, TXT, DBF 和 XML 档案种类）等。新版与任何 MySQL 5.0.x 伺服器版本兼容，支援 Triggers，以及 BINARY VARBINARY/BIT 数据种类等的风范。
下载地址：http://www.navicat.net.cn/index.html
注册码（这个才是重要些东西）
PremiumSoft Navicat for MySQL Enterprise Edition v8.0.27
注册码请点击上面的链接去Tdweb博客进行查询

个人觉得，navicat lite for mysql已经够我们使用了。而且。navicat还有一个缺点，知名博客yhustc的储藏箱里有介绍：害人的海猫，有空可以看看哦

Tags: navicat, 注册码, 数据库, mysql

Software | 评论:0 | 阅读:24807

Submitted by gouki on 2009, May 14, 10:35 PM

2001 年对我自己来说，是一个比较重要的时间点--正式踏上工作岗位，也在这一年奠定了以后工作的技术方向。在 2001年，《程序员》杂志经过两期试刊后也已正式创刊。转眼间，杂志即将出版第 100 期，让人心生感慨。自己几年来持续关注数据库技术领域，《程序员》是一份很重要的参考信息来源。这里回顾一下自《程序员》创刊以来的数据库大事，算是一份纪念，或有谬误，敬请指正。

就从 2001 年说起吧， 2001年6月的ORACLE OpenWorld大会中，ORACLE发布了ORACLE 9i。相比上一个主要版本，也就是 Oracle 8i来说，最大的新产品特性就是真实应用集群(Real Application Clusters, RAC）了。ORACLE 9i的RAC在TPC-C的基准测试中打破了数项记录，一时间业内瞩目。刚在上一年发布 SQL Server 2000 的微软在这一年产品上没什么更大的动作，正在积极拼抢市场。而 MySQL 在 1月份发布了 3.23 产品版，给不少开源爱好者以欣喜。

DB2 在这一年产品上没什么亮点，但是以 10 亿美金收购了 Informix 的数据库的事情震动业界。记得自己当时正好有个 Informix 项目要实施，着实看了几天 Informix 技术文档。这一年国内数据库领域的一件值得一提的小事是 ITpub.net 的创建，这个当初看似不起眼的论坛，在随后的几年中涌现出了一大批数据库技术人才，很大程度上在国内普及了 Oracle 数据库技术。

IBM 推出DB2数据库V8.1的测试版，估计是还在消化 Infomix 的客户资源，几个月之后正式版才能面试。而 Oracle 与 Sun 庆祝了 20 年的合作伙伴关系。之后，Sun 不复 .com 大潮中的明星范儿，Oracle 因为全力支持 Linux 也与 Sun关系愈加微妙。Oracle Open World 第一次在国内举行，地点是北京，会议规格不低，Larry Ellison 在会上进行了主题演讲，此前，这位软件界的传奇人物已经来过中国数次了。[喜欢IT八卦的人可以搜索一下《IT江湖水也深》这篇文章。]

微软连续第二年没有对 SQL Server 发布新版本。

MySQL 发布 4.0 Beta 版。从 4.0 开始，InnoDB 正式成为 MySQL 的默认引擎。在 InnoDB 的基础上，MYSQL对于事务的处理能力有了极大提升。

SQL:2003 发布。这个版本针对 SQL:99 的一些问题进行了改进，支持 XML，支持 Window 函数、Merge 语句等。随着，会看到各大数据库厂商纷纷宣布新的版本中对该标准的支持，这是他们一贯的姿态。

MySQL 4.0 正式发布。在全文索引、嵌入式应用方面得到增强。这个时候的 MySQL 仍然缺乏一些企业级数据库的关键功能。

Oracle 这一年发布了 Oracle 10g， g 代表 Grid ，网格计算。这一年中"网格计算"火爆程度不亚于现在的"云计算"，随后的几年，这个网格计算基本上还只存在于专家们的嘴里。所以，去年 Larry Ellison 在会议上对"云计算"表示不屑也是正常之举。在这一年，Oracle 也宣布针对Linux 64位环境的产品准备就绪，接下来的一年里，Oracle 宣称雇佣了近万人的 Linux 相关的开发人员，可谓不惜血本，当然，这些投入在日后得到了超值回报。从技术的角度上看，其贡献也是有目共睹的，在 I/O 能力、进程扩展能力上都作出很大贡献。

雅虎技术人何伟平的一篇《PostgreSQL 昨天,今天和明天》对于 PostgreSQL 的普及起到了很大作用。

Danga Interactive 针对 LiveJournal.com 开发的Memcached 经过上一年的高频度发布，在这一年只发布了一个版本，标志着已经进入相对稳定阶段，只可惜养在深闺人未必识。关注者并不多。以此为滥觞，伴随着Web 2.0 的火热，类似的分布式对象缓存系统层出不穷，到现在已经成了各大网站标准配备。Memcached 的出现对于数据库方面相关应用设计也带来了更多思路。

这一年嵌入式数据库 SQLite 迎来了较大发展，版本3 完成开发并发布了稳定版。这些努力为 SQLLite 获得 2005 Open Source Award 打下很好的基础。

我自己第一次给技术杂志投稿《书写历史的甲骨文》，当然是发在《程序员》。

PostgreSQL 8.0 的发布宣告正式开始支持 Windows 平台，成为真正意义上的 Windows 平台数据库（Native Server）。这是 PostgreSQL 发展史上相当重要的一件大事。

微软时隔五年，终于发布了 SQL Server 新版，是为 SQL Server 2005。最大亮点在于对 XML 数据的支持，当时不少技术媒体对此都颇为关注。IBM 发布 DB2 V8.2。

Oracle发布了Oracle10g R2 版本，10g 的 R1 版本稳定性广为诟病，R2版本质量有很大增强，一部分用户终于可以放心一点从 9i 升级到 10g。10月，Oracle 抄了MySQL 后路，将 InnoDB 收归帐下。几年过去回头看，Oracle 此举对 MySQL 影响太大，直到现在，MySQL 也没能自己拥有一个超越 InnoDB 的存储引擎，当然，也不可能超出 InnoDB 的在线备份功能。历史不容假设，否则的话，或许 MySQL 最后仍将独立发展也说不定。 MySQL 在这一年发布5.0 Beta版，引入数个新特性，比如存储过程、触发器等，而这些其实是其他主流商业数据库早已实现的功能，从这个角度上看，MySQL和其竞争对手比较，仍然是追赶者，甚至也落后于开源兄弟 PostgreSQL。

IBM 在这一年发布了DB2 V9 ，最大特性是加入了 PureXML 支持。IBM 对 XML 方面寄予厚望，不过时间证明，XML 对于数据库市场的影响并没有那么大。

在嵌入式数据库方面，Oracle 收购 Berkeley DB 的母公司 Sleepycat Software。到此，MySQL 两个最重要的存储引擎都控制在 Oracle 手里(Falcon 引擎开发进度遥遥无期，最后不了了之)，尽管现在来看关系并未僵化，但谁也说不好未来能怎样。Oracle也宣布推出Enterprise Linux，进军操作系统市场，开始和 Linux 厂商之间展开竞争又合作的关系。

SQL:2006发布，继续增强 XML方面的特性。Ingres，这个早期数据库流派的标识产品，以GPL版权形式开放代码。

Oracle 发布 11g 数据库，引入物理 Data Guard 算是最大新功能。MySQL 的拥趸者要偷笑，其实 MySQL 的 Slave DB早就可以在恢复的同时提供查询的能力了。MySQL 宣布将对 5.0 提供两个变种，社区服务器(Community Server)与企业服务器(Enterprise Server)，后者发布周期为1月一次，而社区服务器发布周期则不固定。

随着 Firefox 的发行量增加，其内嵌的SQLite 也赢得了大量部署用户。如果单纯从部署数量来看，SQLite 倒也堪称最流行的DB。

2008年数据库领域的最大的事件，是 Sun 收购 MySQL，价格 10 亿美元。一年多时间过去，回头来看，这次收购对于 MySQL 不是什么好事情。年尾，MySQL 发布 5.1 生产版，质量并不好，引起了不小争议。在这个版本中正式提供对分区(Partition)功能的支持。此外，在这一年中，开源社区对于给MySQL 贡献的补丁和各种解决方案让人眼花缭乱，是可喜之事。Google 和 Facebook 等大站都对 MySQL 作出不小的贡献。

微软发布 SQL Server 2008，没有提供什么更扎眼的功能。其实关系数据库发展到现在，要想作出更大革新已经是几乎不可能的事情了。对于微软来说，Windows平台上 SQL Server 有其压倒性优势，可时过境迁，一方面的优势演变成了其他平台上的劣势。

PostgreSQL 8.3 发布，应该说从2008年开始，PostgreSQL 在市场上表现已经不容小视，以其为基础的集群BI系统 GreenPlum 已经引起了国内不少用户的关注。

SQL 标准SQL:2008 发布。从SQL:99 到 SQL:2009，可以看到标准修订的周期越来越短，多少也反映了对技术的需求之快。

到现在为止，这篇文章还缺席 Sybase 的信息。必须要提一下的是，Sybase 将在3月份公布其列数据库(Column-based Database)的新版本：Sybase IQ 15 。说起来，Sybase 也是传统数据库厂商中唯一提供列数据库的公司。

此外，在云计算应用下涌现出的非关系型数据库(主要是Key/Value存储)产品渐欲迷人眼，有人在疑惑关系数据库已到末日。"关系数据库已死" 每隔几年就会有人跳出来喊，对关系型数据库(RDBMS)来说，百足之虫，死而不僵。

以上只是软件行业发展过程中的一个小小的阶段。如果要做点总结的话，我觉得这几年的值得探讨的一个地方就是 MySQL 的发展模式，从最初的近乎玩具的软件到现在对业界举足轻重的产品，其发展途径值得我们深思。反观国内，我们也有一些所谓的国产数据库，投入重金，多半昙花一现，恐怕技术因素不是主要问题吧?

补充1) 应该说，时间就是善于和人开玩笑。这篇文章写完不久，就传来 Sun 被 Oracle 收购的消息。尽管现在还不能断定收购一定能完成，但这毕竟宣告了有关数据库技术的一个转折点。现在无从判断 MySQL 究竟发展方向如何，也或许，MySQL 的命运掌握在广大用户的手中。

补充2) 其实我非常想写一下"国产数据库"，但出于某种原因考虑，还是放弃了。长期以来，那似乎是和我接触的数据库圈子并行的一个轨道。想来想去，还是不要徒增烦恼了吧。

补充3) 这是个变革的时代，新的数据库产品层出不穷。"乱花渐欲迷人眼"。

补充4) 这篇文章和我参与翻译的 Troubleshooting Oracle Performance 一书，似乎可以用来小声的宣布一件事，那就是我关注的技术领域重心早已不再是数据库了。再见，Database !

原文作者：Feng，来源于：http://www.dbanotes.net/database/database_history_summary_china.html

略有删节（主要是头和尾），本文也可以在《程序员》第100期可以查阅到

Tags: 数据库

DataBase | 评论:0 | 阅读:17833

Submitted by gouki on 2009, January 20, 11:00 PM

本文也是转摘，不过看到它的时候，我想起了discuz的URL解析，discuz在做rewrite的时候，并没有主动都对模版中的链接进行更换，而是在输出前，对于符合规则的那些链接使用rewrite的规范进行了一次批量替换。

这次我转摘的文章也是用了类似的方法，只是他又是.NET处理的，我也不翻译了。知道了原理就行了（和discuz一样，不过这种方法应该只适合做语言包）

原文：

一直以来多语言问题都是个让人头疼的问题，不是这个问题有多难，而是很繁琐，而我们目前的这个项目有点特殊，我希望最大限度的化繁为简，以下是我解决这个问题的方案。
我们的项目有这样两个前提：
1、要支持多语言但最多三种语言，一般情况下就两种语言，所以并没有随时切换语言的要求。
2、我们希望有一种可以初期不用管语言问题，之后统一翻译的方案
基于这么两点，我们提出了这样的方案：
1、初期写程序时不用关心多语言的翻译工作，只要将所有使用到中文的地方都用{}扩上
2、在数据库中Chinese会设置为唯一约束
3、所有的翻译工作会在BasePage中的Render方法中作
4、所有的页面会继承BasePage
5、翻译时会根据当前的语言设置构建以language表中Chinese做key，相应的语言为value的字典，然后查找需要翻译的字符串是不是在字典中，如果不在就生成这一行。

数据库设计四个字段

ID,Chinese,English,Other

BasePage源码：

C#代码

using System;

using System.Data;

using System.Configuration;

using System.Linq;

using System.Web;

using System.Web.Security;

using System.Web.UI;

using System.Web.UI.HtmlControls;

using System.Web.UI.WebControls;

using System.Web.UI.WebControls.WebParts;

using System.Xml.Linq;

using System.Text.RegularExpressions;

using System.Text;

using System.Collections;

using System.Collections.Generic;

using System.IO;

using System.Diagnostics;

/// <summary>

///BasePage 的摘要说明

/// </summary>

public class BasePage : System.Web.UI.Page

{

//利用Dictionary来筛选所有的多语言标签,然后做替换,可以缓存

Dictionary<string, string> dic;

public BasePage()

{

}

//需要替换的标签，标签头为数字字母下划线汉字

static readonly Regex re = new Regex

(@"((\{)|(\%7B))[\w\-\+\|u4e00-\u9fa5]+?((\})|(\%7D))",

RegexOptions.Multiline | RegexOptions.IgnorePatternWhitespace);

//不需要替换的标签

static readonly Regex re_nr = new

Regex(@"<NOREPLACE>[\w\W]*?</NOREPLACE>", RegexOptions.Multiline | RegexOptions.IgnoreCase);

private string RenderTag(ref string content)

{

if (re_nr.IsMatch(content))//不需要替换标签

{

StringBuilder sb = new StringBuilder();

MatchCollection grouplist = re_nr.Matches(content);

string[] reList = re_nr.Split(content);

for (int i = 0; i < grouplist.Count; i++)

{

sb.Append(ReplaceTag(ref reList[i]));

sb.Append(grouplist[i].Value);

sb.Append(ReplaceTag(ref reList[i + 1]));

}

content = sb.ToString();

}

else

{

content = ReplaceTag(ref content);

}

return content;

}

private string ReplaceTag(ref string content)

{

//模板标签{yes},{no},{search}

MatchCollection mc = re.Matches(content);

if (dic == null)

{

dic = LanguageManager.GetResource();

}

for (int i = 0; i < mc.Count; i++)

{

//如果数据库中还没有此字符串

if (!dic.ContainsKey(mc[i].Value.TrimStart('{').TrimEnd('}')))

{

content = content.Replace(mc[i].Value, mc[i].Value.TrimStart('{').TrimEnd('}'));

if (!dic.ContainsKey(mc[i].Value.TrimStart('{').TrimEnd('}')))

{

LanguageManager.AddLanguageString(mc[i].Value.TrimStart('{').TrimEnd('}'));

}

else if (dic[mc[i].Value.TrimStart('{').TrimEnd('}')] == null)

{

content = content.Replace(mc[i].Value, "$$$$");

}

else

{

content = content.Replace(mc[i].Value, dic[mc[i].Value.TrimStart('{').TrimEnd('}')].ToString());

}

return content;

}

protected override void Render(HtmlTextWriter writer)

{

Stopwatch stopwatch = new Stopwatch();

stopwatch.Reset();

stopwatch.Start();

try

{

//会把页面的输出结果存储在这个StringBuilder中

StringBuilder sb = new StringBuilder();

StringWriter sw = new StringWriter(sb);

HtmlTextWriter htw = new HtmlTextWriter(sw);

base.Render(htw);

string content = sb.ToString();

content = RenderTag(ref content);

//重新写入页面

writer.Write(content);

}

catch (Exception ex)

{

Response.Write(ex.ToString());

Response.End();

}

finally

{

stopwatch.Stop();

Response.Write("runtime:" + stopwatch.ElapsedMilliseconds.ToString() + "ms");

}

这样设计的
优点
1、初期写程序时不用关心多语言的翻译工作，只要将所有使用到中文的地方都用{}扩上
2、省去了大量命名相应文字的工作
3、直接用中文标示要显示到页面的文字，容易理解

缺点
1、如果中文是一样的翻译，而其他语言翻译却不一样时不好解决，但这种情况似乎不常见

————————END————————

缺点就是我说的，只能用来做语言包，呵呵。

Tags: web, 语言包, 数据库

PHP | 评论:0 | 阅读:24990

Submitted by gouki on 2009, January 11, 12:27 AM

作者：丁原
地址：http://rdc.taobao.com/blog/dba/html/245_union_index.html

1.SQL需求，统计当天的数据量。

SQL> SELECT count(*) FROM test_union WHERE win_type=1 AND gmt_create >= trunc(sysdate,'dd') and gmt_create <= trunc(sysdate,'dd')+1;

COUNT(*)
----------
20063

1 row selected.

2.查看其索引，以gmt_create开头。

sql>create index idx_union on test_union (gmt_create,win_type) tablespace tbs_index compute statistics;

3.查看awr报表的性能，逻辑读很高，达到9700个。

Buffer Gets Executions Gets per Exec %Total Time Time (s) Hash Value
--------------- ---------- -------------- ------ -------- --------- ------
205,157,987 21,236 9,660.9 34.5 6733.21 7568.58 1532799124
Module: java@app12345 (TNS V1-V3)
SELECT count(*) FROM test_union WHERE win_type=1 AND gmt_create >= trunc(sysdate,'dd') and gmt_create <= trunc(sysdate,'dd')+1

因为是只通过索引扫描，当看到返回结果集在2万左右，我们很容易估算出这个sql需要的逻辑读，(gmt_date字段7个字节+win_type字段1个字节+rowid+…）*2万，小于100个，现在很明显是偏高的。
4.调整前我们先去看数据分布。

SQL> select win_type,count(*) from test_union group by win_type; --按win_type分组
win_type count(*)
---------- ----------
   0 8583162
   1 2725424
   2 765237
   3 2080156
   4 2090871
   5 3568682
SQL> select count(*) from test_union where gmt_create >= trunc(sysdate,'dd') and gmt_create <= trunc(sysdate,'dd')+1; --按gmt_create统计，一天数据量在22万左右

COUNT(*)
----------
   229857

1 row selected.

5.调整索引,改为以win_type开头，为什么要以win_type开头呢？

create index idx_union123 on test_union (win_type,gmt_create) tablespace tbs_index compute statistics; --新索引

6.查看其执行计划，逻辑读变成了89。

sql>set auto traceonly
sql> select count(*) from test_union
where win_type=1 and gmt_create >= trunc(sysdate,'dd') and gmt_create <= trunc(sysdate,'dd')+1;

Elapsed: 00:00:07.17

Execution Plan
----------------------------------------------------------
   0 SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=1 Bytes=9)
   1 0 SORT (AGGREGATE)
   2 1 FILTER
   3 2 INDEX (RANGE SCAN) OF 'idx_union123' (NO
   N-UNIQUE) (Cost=7 Card=1 Bytes=9)
Statistics
----------------------------------------------------------
   0 recursive calls
   0 db block gets
   89 consistent gets
   0 physical reads
   0 redo size
   493 bytes sent via SQL*Net to client
   655 bytes received via SQL*Net from client
   2 SQL*Net roundtrips to/from client
   0 sorts (memory)
   0 sorts (disk)
   1 rows processed

都在说建索引一定要看数据分布，从数据分布来看，一天的的数据(gmt_create)量在22万左右，而win_type的数据量非常大，win_type为1有300万左右，为什么还要把win_type放在索引的前面呢？抛块砖，希望大家能对联合索引有更深入的理解，希望一起讨论。

--EOF--

帖子下的几个评论也很有意思：

XML/HTML代码

1. 1棉花糖ONE
hehe，所以我在itpub上经常建议人家如果是建复合索引的话，把范围查询的谓词尽量放在后面，这样能增加木匠说的有效索引选择度，对oracle执行计划的判断有意义，当然更主要的是这样创建索引确实是减少了索引扫描的范围,不知道楼主的环境还在不在，根据数据来看，这２个字段是相关的，而且楼主恰好查询的是 count(*)，可以不扫描表，走复合索引就比较正常，如果是select * from … ,这样很可能就不会选择走索引，就11g以前除了动态采样，加hint，统计信息上应该是搞不对，我测试了11g的扩展列的统计信息，感觉这玩意效果没有想象中的理想
Comment on Jan 10th, 2009 at 9:58 am
2. 2木匠
如果没有搞清楚SQL optimizer engine and Run time engine怎么工作,怎么使用composite index,
你的观测结果只是表面现象,永远也不知道为什么.
查看数据分布是对的,
但是这种情况是需要寻根问底的. my CA$0.02 + tax, 我的一点建议.
木匠不辞劳苦,再重复一遍SQL optimizer and runtime engine 是怎么工作的:
as soon as we have a range scan on a column used somewhere in the
middle of an index definition or fail to supply a test on such a column, the predicates on later columns do not restrict the selection of index leaf blocks that we have to examine.
In this case, the effective index selectivity has to be calculated from the predicate on just the “gmt_create” column. Because the test on “gmt_create” is range-based, the predicates on “win_type” do not restrict the number of index leaf blocks we have to walk.
关键字: effective index selectivity.
Comment on Jan 10th, 2009 at 1:49 am
3. 3丁原
这个案例已经很久了。
实际上是没有打算写的，这个例子一直有人在问为什么，问的多了，我干脆就邮件中的内容整理出来，大家讨论加深印象。
我尝试把线上的数据拉下来做测试，发觉太大了根本拉不下来，只能是拼拼凑凑，gmt_create的索引已经drop掉了，部分测试数据可能不那么准确，但是数据还是在范围之内，不会偏差很大。
逻辑读怎么算？
select (7+1+rowid+..)*20000/8192，差不多就是我们要的逻辑读。
to木匠：cost不一定准确的，我更多的是查看数据分布，结果集，以逻辑读来判断。
to棉花糖：回复有审核的，防止很多垃圾广告。
Comment on Jan 9th, 2009 at 5:11 pm
4. 4carcase
win_type，gmt_create 扫描的索引块少多了，确定了win_type=1的范围后，再确定了是当天的数据
（索引是win_type,gmt_create 排序的，范围扫描马上能定位到当天的数据）也就扫描了2万多就够了，速度得到了提升。
和
gmt_create，win_type 扫描的索引块多了很多，相当于扫描了 gmt_create当天所有的数据了，22万多数据都要扫描一遍，过滤出win_type=1 的数据
Comment on Jan 9th, 2009 at 11:05 am
5. 5棉花糖ONE
Your comment is awaiting moderation.
到底咋回事啊
Comment on Jan 9th, 2009 at 10:45 am
6. 6棉花糖ONE
逻辑读89是不是搞错了
Comment on Jan 9th, 2009 at 10:45 am
7. 7jlttt
我们很容易估算出这个sql需要的逻辑读，(gmt_date字段7个字节+win_type字段1个字节+rowid+…）*2万，小于100个
（7＋1＋10＋…）×2W 所读的块怎么算出小于100的？
Comment on Jan 9th, 2009 at 9:46 am
8. 8棉花糖ONE
to 木匠:
cardinality=1可能和9i有关,sysdate包含函数计算的时候,没有直方图的情况下,范围查询的选择度是按5%算的,2个5%*5%
Comment on Jan 9th, 2009 at 9:42 am
9. 9棉花糖ONE
如果把范围的放前面,索引的第二个字段只是起到filter的作用,并没有减少索引扫描的块,从索引的成本计算也能看出这一点
Comment on Jan 9th, 2009 at 9:36 am
10. 10木匠
对不起,再唠叨一句.
除了比较cost,还要比较Cardinality, 第二个SQL,index scan这一步的Card=1.
但是我觉得index scan这一步的Cardinality应该大于一, 不知道哪里出了问题.
每一个Oracle版本的Cost and Card会有不同的结果.9.2.0.6 and 10.1.0.4或更高版本会提供更有用的信息.
(木匠真够粗心大意的, 请包涵)
Comment on Jan 9th, 2009 at 2:26 am
11. 11木匠
In this case, the effective index selectivity has to be calculated from the predicate on just the “gmt_create” column. Because the test on “gmt_create” is range-based, the predicates on “win_type” do not restrict the number of index leaf blocks we have to walk.
照搬老刘(Lewis)的原话, 改一下列名就行了. :)
上一个评论中的cost 指的是整个SQL(with index scan)的cost.
另外, 你忘了记录走第一个索引的SQL执行计划,可以比较一下 INDEX (RANGE SCAN) 的 cost.
INDEX (RANGE SCAN) OF ‘idx_union123′ (NON-UNIQUE) (Cost=7 Card=1 Bytes=9), 我们看到走第二个索引的(index range scan) cost=7.
Comment on Jan 9th, 2009 at 2:03 am
12. 12木匠
Q: 为什么还要把win_type放在索引的前面呢？
A: leaf_blocks * effective index selectivity
第一个索引, range scan on gmt_create, first column on index.
Because as soon as we have a range scan on a column used somewhere in the
middle of an index definition or fail to supply a test on such a column, the predicates on later columns do not restrict the selection of index leaf blocks that we have to examine.
参考:
cost =
blevel +
ceiling(leaf_blocks * effective index selectivity) +
ceiling(clustering_factor * effective table selectivity)
a well-known guideline for arranging the columns in a multicolumn
index. Columns that usually appear with range-based tests should generally appear later in the index than columns that usually appear with equality tests. Unfortunately, changing the column ordering in an index can have other contrary effects, which we will examine in Chapter 5.
Now you got test case. very well ! ^_^
Reference: page 74,62,67 of book Cost-Based Oracle Fundamentals
Comment on Jan 9th, 2009 at 1:52 am

Tags: 索引, mysql, 联合索引, 数据库

DataBase | 评论:1 | 阅读:37849

Records:1412 3 ›

« 2024年11月 »