数码天地 今日: 0|主题: 4756|排名: 52 

最后发表： earthengine
回复内容：

理论上，用一条SQL语句是可以完成的，见下：
SELECT
  MIN((SELECT COUNT(*) FROM temptest1 a WHERE a.x<=b.x) ) AS x0,
  SUM( (CASE WHEN y=0 THEN 1 ELSE 0 END) ) AS y0,
  SUM( (CASE WHEN y=1 THEN 1 ELSE 0 END) ) AS y1,
  SUM( (CASE WHEN y=2 THEN 1 ELSE 0 END) ) AS y2,
  SUM( (CASE WHEN y=3 THEN 1 ELSE 0 END) ) AS y3
FROM temptest1 b
GROUP BY ( ((SELECT COUNT(*) FROM temptest1 a WHERE a.x<=b.x)-1)/40)
ORDER BY x0

不过如你所说，这样做有很大的效率问题。
为了提高效率，可以考虑采用临时表方案：
CREATE TABLE temp (x int,recno int)

INSERT INTO temp (x,recno)
SELECT x, (SELECT count(*) FROM temptest1 a WHERE a.x<=b.x)
FROM temptest1 a

SELECT min(b.x) AS x0,
   SUM (CASE WHEN y=0 THEN 1 ELSE 0 END) AS y0,
   SUM (CASE WHEN y=1 THEN 1 ELSE 0 END) AS y1,
   SUM (CASE WHEN y=2 THEN 1 ELSE 0 END) AS y2,
   SUM (CASE WHEN y=3 THEN 1 ELSE 0 END) AS y3
FROM temptest1 INNER JOIN temp b ON a.x=b.x
GROUP BY (b.recno-1)/40
ORDER BY x0

DROP TABLE temp

最后发表： GPS
回复内容：
POSTGRESQL 可以用C来写扩展函数， 有哪位知道，能不能在这些扩展函数中， 读写本地文件，或者读写socket的？ 大概有哪些限制呢？ 在Linux下的。

最后发表： sliuhao
回复内容：
cloudscape

最后发表： zycbob
回复内容：
好像没有分组，不过实现也不难，主要是mysql不支持~

最后发表： cicada2006
回复内容：
new tools, a piece of blue sky
thanks

最后发表： coredump
回复内容：
谢谢提醒，呵呵。这个表A中的b严格说还必须是指向表B的外键

最后发表： qunlbao
回复内容：
这种都是不甘心看oracle,sql server统领市场，喜欢搞open source的
技术派的单纯想法，要想真正走出自己的路太难，作市场不是这么容易，
况且dbms/sql是多么成熟的技术。
google用自己的技术是因为sql在做search engine方面可能不是最好的选择，
尤其是在海量数据检索方面，不过要想推广到其他企业级的应用上就是另外
一回事了

最后发表： wukong
回复内容：

每太看懂这个问题是什么意思， ‘分成 多个group by’ ？？

使用group by的时候还可以用上 with cube 和with rollup
with rollup 给出每一级分组的累计值统计，从第一级分组字段到最后一级，order by会决定这种分级结构
例如 order by year, quarter, month

year   quarter   month    sum
null   null        null     1660
2008    null        null   1000
2008    4        null     1000
2008    4       12        1000
2009    null     null     660
2009    1        null     60
2009    1        1         10
2009    1        2         20
2009    1        3         30
2009    2        null     600
2009    2       4        100
2009    2        5         200
2009    2        6         300


with cube 会产生另外一种结果
例如 order by year, quarter, month

year   quarter   month    sum
null   null        null     1660
null   null        1       10
......
null   null        5       200
null   null        6       1300
null   1          1        10
...
null   2          6        1300  (2008.6 quarter 2 + 2009.6 quarter 2)
2008    null        null   1000
2008    2        null     1000
2008    2       6         1000
2009    null     null     660
2009    1        null     60
2009    1        1         10
2009    1        2         20
2009    1        3         30
2009    2        null     600
2009    2       4        100
2009    2        5         200
2009    2        6         300

另外还可以用 having 子句去 筛选

group by year, quarter, month having sum(sum) > 500
结果集里只包含汇总金额大于500的那些记录

      快速回复

最后发表： GPS
回复内容：
我都对了， 不过确实没太多意义。现实比这复杂太多了。

最后发表： ubuntuhk
回复内容：
虽然这篇文章有点老，但是对于MySQL建立索引的优化原则，基本上还是有效的：

===============================

MySQL索引分析和优化              

作者:松下客 来源:赛迪网

一、什么是索引？ 索引用来快速地寻找那些具有特定值的记录，所有MySQL索引都以B-树的形式保存。如果没有索引，执行查询时MySQL必须从第一个记录开始扫描整个表的所有记录，直至找到符合要求的记录。表里面的记录数量越多，这个操作的代价就越高。如果作为搜索条件的列上已经创建了索引，MySQL无需扫描任何记录即可迅速得到目标记录所在的位置。如果表有1000个记录，通过索引查找记录至少要比顺序扫描记录快100倍。 假设我们创建了一个名为people的表： CREATE TABLE people ( peopleid SMALLINT NOT NULL, name CHAR(50) NOT NULL ); 然后，我们完全随机把1000个不同name值插入到people表。下图显示了people表所在数据文件的一小部分：                                 登录/注册后可看大图 可以看到，在数据文件中name列没有任何明确的次序。如果我们创建了name列的索引，MySQL将在索引中排序name列：                                 登录/注册后可看大图 对于索引中的每一项，MySQL在内部为它保存一个数据文件中实际记录所在位置的“指针”。因此，如果我们要查找name等于“Mike”记录的peopleid（SQL命令为“SELECT peopleid FROM people WHEREname=\'Mike\';”），MySQL能够在name的索引中查找“Mike”值，然后直接转到数据文件中相应的行，准确地返回该行的peopleid（999）。在这个过程中，MySQL只需处理一个行就可以返回结果。如果没有“name”列的索引，MySQL要扫描数据文件中的所有记录，即1000个记录！显然，需要MySQL处理的记录数量越少，则它完成任务的速度就越快。 二、索引的类型 　　MySQL提供多种索引类型供选择： 普通索引 这是最基本的索引类型，而且它没有唯一性之类的限制。普通索引可以通过以下几种方式创建： 创建索引，例如CREATE INDEX <索引的名字> ON tablename (列的列表); 修改表，例如ALTER TABLE tablename ADD INDEX [索引的名字] (列的列表); 创建表的时候指定索引，例如CREATE TABLE tablename ( [...], INDEX [索引的名字] (列的列表) ); 唯一性索引 这种索引和前面的“普通索引”基本相同，但有一个区别：索引列的所有值都只能出现一次，即必须唯一。唯一性索引可以用以下几种方式创建： 创建索引，例如CREATE UNIQUE INDEX <索引的名字> ON tablename (列的列表); 修改表，例如ALTER TABLE tablename ADD UNIQUE [索引的名字] (列的列表); 创建表的时候指定索引，例如CREATE TABLE tablename ( [...], UNIQUE [索引的名字] (列的列表) ); 主键 主键是一种唯一性索引，但它必须指定为“PRIMARYKEY”。如果你曾经用过AUTO_INCREMENT类型的列，你可能已经熟悉主键之类的概念了。主键一般在创建表的时候指定，例如“CREATETABLE tablename ( [...], PRIMARY KEY (列的列表) );”。但是，我们也可以通过修改表的方式加入主键，例如“ALTER TABLE tablename ADD PRIMARY KEY (列的列表);”。每个表只能有一个主键。 全文索引 MySQL从3.23.23版开始支持全文索引和全文检索。在MySQL中，全文索引的索引类型为FULLTEXT。全文索引可以在VARCHAR或者TEXT类型的列上创建。它可以通过CREATE TABLE命令创建，也可以通过ALTERTABLE或CREATE INDEX命令创建。对于大规模的数据集，通过ALTER TABLE（或者CREATEINDEX）命令创建全文索引要比把记录插入带有全文索引的空表更快。本文下面的讨论不再涉及全文索引，要了解更多信息，请参见[url=http://www.phpe.net/articles/%5C%22http://www.mysql.com/doc/F/u/Fulltext_Search.html%5C%22]MySQL documentation[/url]。 三、单列索引与多列索引 索引可以是单列索引，也可以是多列索引。下面我们通过具体的例子来说明这两种索引的区别。假设有这样一个people表： CREATE TABLE people ( peopleid SMALLINT NOT NULLAUTO_INCREMENT, firstname CHAR(50) NOT NULL, lastname CHAR(50) NOTNULL, age SMALLINT NOT NULL, townid SMALLINT NOT NULL, PRIMARY KEY(peopleid) ); 下面是我们插入到这个people表的数据：                                 登录/注册后可看大图 这个数据片段中有四个名字为“Mikes”的人（其中两个姓Sullivans，两个姓McConnells），有两个年龄为17岁的人，还有一个名字与众不同的Joe Smith。 这个表的主要用途是根据指定的用户姓、名以及年龄返回相应的peopleid。例如，我们可能需要查找姓名为Mike Sullivan、年龄17岁用户的peopleid（SQL命令为SELECT peopleid FROM people WHEREfirstname=\'Mike\' AND lastname=\'Sullivan\' ANDage=17;）。由于我们不想让MySQL每次执行查询就去扫描整个表，这里需要考虑运用索引。 首先，我们可以考虑在单个列上创建索引，比如firstname、lastname或者age列。如果我们创建firstname列的索引（ALTER TABLE people ADD INDEX firstname(firstname);），MySQL将通过这个索引迅速把搜索范围限制到那些firstname=\'Mike\'的记录，然后再在这个“中间结果集”上进行其他条件的搜索：它首先排除那些lastname不等于“Sullivan”的记录，然后排除那些age不等于17的记录。当记录满足所有搜索条件之后，MySQL就返回最终的搜索结果。 由于建立了firstname列的索引，与执行表的完全扫描相比，MySQL的效率提高了很多，但我们要求MySQL扫描的记录数量仍旧远远超过了实际所需要的。虽然我们可以删除firstname列上的索引，再创建lastname或者age列的索引，但总地看来，不论在哪个列上创建索引搜索效率仍旧相似。 为了提高搜索效率，我们需要考虑运用多列索引。如果为firstname、lastname和age这三个列创建一个多列索引，MySQL只需一次检索就能够找出正确的结果！下面是创建这个多列索引的SQL命令： ALTER TABLE people ADD INDEX fname_lname_age (firstname,lastname,age); 由于索引文件以B-树格式保存，MySQL能够立即转到合适的firstname，然后再转到合适的lastname，最后转到合适的age。在没有扫描数据文件任何一个记录的情况下，MySQL就正确地找出了搜索的目标记录！ 那么，如果在firstname、lastname、age这三个列上分别创建单列索引，效果是否和创建一个firstname、lastname、age的多列索引一样呢？答案是否定的，两者完全不同。当我们执行查询的时候，MySQL只能使用一个索引。如果你有三个单列的索引，MySQL会试图选择一个限制最严格的索引。但是，即使是限制最严格的单列索引，它的限制能力也肯定远远低于firstname、lastname、age这三个列上的多列索引。 四、最左前缀 多列索引还有另外一个优点，它通过称为最左前缀（LeftmostPrefixing）的概念体现出来。继续考虑前面的例子，现在我们有一个firstname、lastname、age列上的多列索引，我们称这个索引为fname_lname_age。当搜索条件是以下各种列的组合时，MySQL将使用fname_lname_age索引： firstname，lastname，age firstname，lastname firstname 从另一方面理解，它相当于我们创建了(firstname，lastname，age)、(firstname，lastname)以及(firstname)这些列组合上的索引。下面这些查询都能够使用这个fname_lname_age索引： SELECT peopleid FROM people WHERE firstname=\'Mike\'AND lastname=\'Sullivan\' AND age=\'17\'; SELECT peopleid FROM peopleWHERE firstname=\'Mike\' AND lastname=\'Sullivan\'; SELECT peopleidFROM people WHERE firstname=\'Mike\'; The following queries cannot usethe index at all: SELECT peopleid FROM people WHERElastname=\'Sullivan\'; SELECT peopleid FROM people WHERE age=\'17\';SELECT peopleid FROM people WHERE lastname=\'Sullivan\' AND age=\'17\'; 五、选择索引列 在性能优化过程中，选择在哪些列上创建索引是最重要的步骤之一。可以考虑使用索引的主要有两种类型的列：在WHERE子句中出现的列，在join子句中出现的列。请看下面这个查询： SELECT age ## 不使用索引 FROM people WHERE firstname=\'Mike\' ## 考虑使用索引 AND lastname=\'Sullivan\' ## 考虑使用索引 这个查询与前面的查询略有不同，但仍属于简单查询。由于age是在SELECT部分被引用，MySQL不会用它来限制列选择操作。因此，对于这个查询来说，创建age列的索引没有什么必要。下面是一个更复杂的例子： SELECT people.age, ##不使用索引 town.name ##不使用索引 FROMpeople LEFT JOIN town ON people.townid=town.townid ##考虑使用索引 WHEREfirstname=\'Mike\' ##考虑使用索引 AND lastname=\'Sullivan\' ##考虑使用索引 与前面的例子一样，由于firstname和lastname出现在WHERE子句中，因此这两个列仍旧有创建索引的必要。除此之外，由于town表的townid列出现在join子句中，因此我们需要考虑创建该列的索引。 那么，我们是否可以简单地认为应该索引WHERE子句和join子句中出现的每一个列呢？差不多如此，但并不完全。我们还必须考虑到对列进行比较的操作符类型。MySQL只有对以下操作符才使用索引：<，<=，=，>，>=，BETWEEN，IN，以及某些时候的LIKE。可以在LIKE操作中使用索引的情形是指另一个操作数不是以通配符（%或者_）开头的情形。例如，“SELECT peopleid FROM people WHERE firstname LIKE\'Mich%\';”这个查询将使用索引，但“SELECT peopleid FROM people WHERE firstname LIKE\'%ike\';”这个查询不会使用索引。 六、分析索引效率 现在我们已经知道了一些如何选择索引列的知识，但还无法判断哪一个最有效。MySQL提供了一个内建的SQL命令帮助我们完成这个任务，这就是EXPLAIN命令。EXPLAIN命令的一般语法是：EXPLAIN <SQL命令>。你可以在MySQL文档找到有关该命令的更多说明。下面是一个例子： EXPLAIN SELECT peopleid FROM people WHERE firstname=\'Mike\' AND lastname=\'Sullivan\' AND age=\'17\'; 这个命令将返回下面这种分析结果： table type possible_keys key key_len ref rows Extra people ref fname_lname_age fname_lname_age 102 const,const,const 1 Where used 下面我们就来看看这个EXPLAIN分析结果的含义。 table：这是表的名字。 type：连接操作的类型。下面是MySQL文档关于ref连接类型的说明： “对于每一种与另一个表中记录的组合，MySQL将从当前的表读取所有带有匹配索引值的记录。如果连接操作只使用键的最左前缀，或者如果键不是UNIQUE或PRIMARYKEY类型（换句话说，如果连接操作不能根据键值选择出唯一行），则MySQL使用ref连接类型。如果连接操作所用的键只匹配少量的记录，则ref是一种好的连接类型。” 在本例中，由于索引不是UNIQUE类型，ref是我们能够得到的最好连接类型。 如果EXPLAIN显示连接类型是“ALL”，而且你并不想从表里面选择出大多数记录，那么MySQL的操作效率将非常低，因为它要扫描整个表。你可以加入更多的索引来解决这个问题。预知更多信息，请参见MySQL的手册说明。 possible_keys： 可能可以利用的索引的名字。这里的索引名字是创建索引时指定的索引昵称；如果索引没有昵称，则默认显示的是索引中第一个列的名字（在本例中，它是“firstname”）。默认索引名字的含义往往不是很明显。 Key： 它显示了MySQL实际使用的索引的名字。如果它为空（或NULL），则MySQL不使用索引。 key_len： 索引中被使用部分的长度，以字节计。在本例中，key_len是102，其中firstname占50字节，lastname占50字节，age占2字节。如果MySQL只使用索引中的firstname部分，则key_len将是50。 ref： 它显示的是列的名字（或单词“const”），MySQL将根据这些列来选择行。在本例中，MySQL根据三个常量选择行。 rows： MySQL所认为的它在找到正确的结果之前必须扫描的记录数。显然，这里最理想的数字就是1。 Extra： 这里可能出现许多不同的选项，其中大多数将对查询产生负面影响。在本例中，MySQL只是提醒我们它将用WHERE子句限制搜索结果集。 七、索引的缺点 到目前为止，我们讨论的都是索引的优点。事实上，索引也是有缺点的。 首先，索引要占用磁盘空间。通常情况下，这个问题不是很突出。但是，如果你创建每一种可能列组合的索引，索引文件体积的增长速度将远远超过数据文件。如果你有一个很大的表，索引文件的大小可能达到操作系统允许的最大文件限制。 第二，对于需要写入数据的操作，比如DELETE、UPDATE以及INSERT操作，索引会降低它们的速度。这是因为MySQL不仅要把改动数据写入数据文件，而且它还要把这些改动写入索引文件。 【结束语】在大型数据库中，索引是提高速度的一个关键因素。不管表的结构是多么简单，一次500000行的表扫描操作无论如何不会快。如果你的网站上也有这种大规模的表，那么你确实应该花些时间去分析可以采用哪些索引，并考虑是否可以改写查询以优化应用。要了解更多信息，请参见MySQL manual。另外注意，本文假定你所使用的MySQL是3.23版，部分查询不能在3.22版MySQL上执行。

转自：http://www.phpe.net/articles/323.shtml

最后发表： ubuntuhk
回复内容：
最近在研究discuz里面的SQL语句优化，这篇帖子分析得不错，很有参考意义，发上来和大家一起分享。

（转帖过来格式有点乱，大家可以到原文地址去查看，后面还有不少评论也很不错。）

最后发表： ubuntuhk
回复内容：
mysql怎样执行orderby  
                    Joomla! 开源天空           作者：管理员           2009-03-06 21:39            
             

• 摘要：这篇文章对于mysql order by的执行方式，涉及到的细节做出了深入的描述。非常好，有空一定要翻译一下。
• 
  

          
                              Inlast couple of weeks there has been a tide of ORDER/GROUP BY-relatedoptimization bugs, where I was the fixer or the reviewer. This wasn'tan easy job because there is no sane description of how GROUP BY/ORDERBY handling is supposed to work.
To figure it out, I had to write an explanation of how it works. Thefirst part is about ORDER BY. Hopefully there will be subsequent partsthat will show how GROUP BY is related to ORDER BY and how it works.
Available means to produce ordered sequencesMySQL has two methods to produce ordered streams.
The first is to use a "range", "ref" or "index"access method over an ordered index. For versions up to 5.1, thoseaccess methods naturally return records in the index order, so we getordering for free (the exception is NDB engine which needs to domerge-sort when it gets data from several storage nodes). In MySQL 5.2,MyISAM and InnoDB have MultiRangeRead optimizationwhich breaks the ordering. We have a draft of how to make it preservethe ordering, but at the moment MRR is simply disabled wheneverordering is required.
The second, catch-all method, is to use the filesortalgorithm. In a nutshell, filesort() does quicksort on chunks of datathat fit into its memory and then uses mergesort approach to merge thechunks. The amount of memory available to filesort() is controlled by @@sort_buffer_sizevariable. if the sorted data doesn't fit into memory (i.e. there ismore than one chunk), filesort uses a temporary file to store thechunks.
Source data for filesort() always comes from one table. If there isa need to sort data from several tables, MySQL will first collect thedata into a temporary table and then invoke filesort() for thattemporary table. I don't know the true reason for this. Codewise,filesort() wants to pull its source data using something likesource.get_next_record() function, while join and union runtime producetheir using result.put_next_record()-type calls, so maybe the temporarytable is there only to resolve this push/pull mismatch and will go awayonce we get decent cursors.
filesort() has two modes of operation:

• Mode 1: the sorted elements contain all required columns of thesource table. The result of the sorting is a linear sequence of outputtuples, there is no need to access the source table after the sort isdone.
• Mode 2: sort <sort_key, rowid> pairs and produce asequence of rowids which one can use to get source table's rows in therequired order (but this will be essentially hit the table in randomorder and is not very fast)

Mode 1 is used whenever possible. Mode is used when mode1 is notapplicable. This is the case when the sorted tuples have blobs orvariable-length columns (TODO: check w/ evgen). Unfortunately, theEXPLAIN output provides no clue about which mode is used, so you'llhave to manually check for blobs in the output columns list.
Executing join to produce ordered streamAt the moment MySQL has three ways to run a join and produce ordered output:

Method	EXPLAIN output
Use index-based access method that produces ordered output	no mention of filesort
Use filesort() on 1st non-constant table	"Using filesort" in the first row
Put join result into a temporary table and use filesort() on it	"Using temporary; Using filesort" in the first row

Now I'll cover those three methods in more detail. The first methodcan be used when the first non-const table in the join order has anindex that matches the ORDER BY list. In this case we can use theindex, and the ordering will "spread over" other tables onto theoutput. Here is a swimlane diagram of this process, where differentcolumns represent different values of the ORDER BY expression:


This method is preferred over the other two as it requires no additional sorting steps.
The second method can be used when all ORDER BY elements refer tothe first table in the join order. In this case, we can filesort() thefirst table and then proceed to execute the join:


Herefilesort() may operate either in Mode 1 or in Mode 2. One may wonderwhy this is limited to doing filesort() after the first table. Afterall, we could do it after the second table as well - produce (tbl1,tbl2) record combinations, put them into temporary table, sort, etc.The expectation is perfectly reasonable but alas, MySQL will not evenconsider such query plans.
The last, the catch-all method is to write the entire join output into the temporary table and then invoke filesort:


I have an easier time recalling those three strategies when thereare pictures, hopefully they'll help you too. That's all for today, innext posts I'll cover the topics of how ordering affects joinoptimization and interoperates with GROUP BY.
原文：http://s.petrunia.net/blog/?p=24

转自：http://www.maycode.com/index.php ... ews/1417-mysql.html

最后发表： godspeed
回复内容：
要向kingking多学习。

最后发表： yuba
回复内容：
MySQL 5.1拥有多项新的企业级增强特性，它们是：
1.表格和索引的分区特性 —— MySQL 5.1支持5种形式的水平数据分区：range、hash、key、list和复合composite分区(子分区)。通过表格和索引数据的分区，可做到仅仅是对需要的相关数据分区进行扫描，而不是扫描整个的表格和索引，因此就获得了更快速的查询响应。而且，有了分区特性，许多存储和其他维护操作变得更加容易和快速。

2.基于单元（row-based）的复制和混合复制特性 —— 这是MySQL 5.1内提供的两个新的复制选项。“基于单元的复制”是复制主服务器和从服务器之间的数据变化(而不是实际的SQL语句)，而“混合复制”采用的或是基于语句复制，或是基于单元的复制，这取决于一个个的SQL操作  —— 对于应用来讲，这就形成并保持了最有效的和最安全的复制机制。

3.事件调度特性 —— 这是一个新的工具，它可让开发者和经营管理学博士自动调度数据库服务器上要执行的、通用的基于SQL的循环（recurring）任务。这一特性比起Linux或Unix中的CRON，或Microsoft Windows的任务调度程序，可对数据库特定的任务提供更大的支持。

4.新的MySQL Query Analyzer (查询分析器) —— 享受优惠的MySQL Enterprise订购项目将提供Sun的这一新的MySQL Query Analyzer工具，该工具通过监控查询性能来精确定位和修改有问题的SQL 代码，可以大大改善MySQL数据库应用的速度和正常运行时间。包括这一新的MySQL Query Analyzer在内的对MySQL Enterprise服务的“30天试订购”项目，现在可从http://www.mysql.com/trials免费获得。

“我们测试了其他的一些数据库，但是还没有发现任何数据库能像MySQL 5.1中分区表格那样对我们的数据集进行那么快的查询，”Parallel有限公司首席技术官Guy Adams说。Parallel有限公司是一家卫星管理和网络运营软件的供应商，它为全球最大的一些通信公司供货。

平台支持与供货信息
MySQL 5.1可在许多种类的硬软件平台上工作，包括Red Hat Enterprise Linux、SuSE Enterprise Linux Server、Microsoft Windows、Solaris 10 Operating System (OS)、 Macintosh OS X、Free BSD、HP-UX、IBM AIX、IBM i5/OS，以及其他通用的Linux版本。

MySQL 5.1 GA版现通过以下三种模式提供，以满足不同用户的各种特殊需求：

1.MySQL Community Server —— Sun的MySQL 数据库的免费开源版。这一GPL许可的全功能软件的目标用户是个人技术用户，他不需要商业支持或是享有优惠的机上服务。

2.MySQL Enterprise Server —— 它作为MySQL Enterprise订购的一部分来提供，它最可靠、最安全，提供的是MySQL数据库的最新版本，其目标用户是有法人的IT用户。该模式的订户每月可收到快速软件升级服务，每个季度可收到带有最新补丁程序的“服务包” —— 还能访问仅供预览的监测工具，享受全天候7*24的生产技术支持。

3.MySQL Embedded Server —— 这是MySQL软件的商业许可模式，让ISV和OEM将一个高速的、占用空间很小的数据库嵌入或打包到他们自己的产品中，而不需要免费的GPL许可。

[ 本帖最后由 yuba 于 10-12-2008 16:10 编辑 ]

最后发表： chubbycat
回复内容：
甲骨文与惠普合作：系统走向软硬结合
DWNEWS.COM-- 2008年9月26日20:30:10(京港台时间) --多维新闻网

来源：08-09-27 07:39 比特网

　　比特网(Chinabyte)9月27日消息(王允) 一个软件巨头不干正事，开始卖硬件了。

　　在25号的旧金山甲骨文全球大会(Oracle Open World)上，拉里·埃里森向超过四万名参会者展示了与惠普合作的HP Oracle数据库机——Exadata。

　　这台被称为史上最快数据存储系统的机器由甲骨文和惠普共同耗时三年研制成功，在处理4.5TB电话记录的数据时，与现有的设备两台IBM 570服务器和一台EMC CX3-40存储相比，采用HP ORALCE新型数据存储设备仅采用一半的配置，性能就达到前者的28倍;而与一台硬件配置完全相同的NETAPP存储阵列相比，HP Oracle的存储设备性能也惊人地达到前者30倍。

　　实际上这台机器的产品不仅仅有着惠普和甲骨文的努力，Voltaire InfiniBand也在其中起到了很大的作用，保证了数据交换中的速度。

　　事实上，此前我们也看到很多软件厂商与硬件厂商合作，比如联想与微软合作推出预装Windows Server2008服务器等，但是将自己的名字放到产品中的，甲骨文还是第一个。

　　据了解，甲骨文将负责产品的销售与系统支持，惠普公司则负责硬件的交付与服务。由此可见，双方的合作分工是很明确的，产品也将会冠以两家的品牌。

　　前不久NEC与Unisys合作推出的96核处理器服务器则不同。产品尽管是共同研发，但是却以各自的品牌推出、销售。与甲骨文、惠普的合作完全不同。软硬件厂商共同合作的好处是显而易见的：各自发挥长处，使得产品达到最佳。拉里也说：这是为Oracle数据仓库打造的高性能智能存储设备。

　　HP Oracle Exadata的表现也证明了双方合作的成功。就是不知道，这能坚持多久呢?

最后发表： xblues
回复内容：
调试Discuz临时需要了解一些MySQL的用法，用论坛做笔记很方便。

最后发表： akai
回复内容：
哥们是备份的吧。

最后发表： Coolioo
回复内容：
在TOAD for SQL Server里面如何给Column加 Comment？

Oracle 内建对Comment的支持，但是SQL Server没有。TOAD for SQL Server 里面的Table Column的Comment是不可编辑的。有什么解决办法吗？