手机浏览 RSS 2.0 订阅 膘叔的简单人生 , 腾讯云RDS购买 | 超便宜的Vultr , 注册 | 登陆
浏览模式: 标准 | 列表Tag:database

Infomation:WebKit Does HTML5 Client-side Database Storage

资料备份,其中有两个链接很重要 :
原资料中的:client-side database storage.已经打不开了,好象是换成这个了:10.1.2.2 A worker for updating a client-side database
但我也说不准,详情还是看这个页面吧:http://www.whatwg.org/specs/web-apps/current-work/multipage/

对了,因为是基于webkit的,所以,FF上是没法用的。更多的还是用于ipad,iphone之类的上面吧。

jQueryMobile的代码里应该是有了

WebKit Does HTML5 Client-side Database Storage

Posted by Brady Eidson on Friday, October 19th, 2007 at 4:04 pm

The current working spec for the HTML5 standard has a lot of exciting features we would eventually like to implement in WebKit. One feature we felt was exciting enough to tackle now even though the spec is still in flux is client-side database storage. So for the last few weeks andersca, xenon, and I have been cooking up an implementation!

The client-side database storage API allows web applications to store structured data locally using a medium many web developers are already familiar with – SQL.

The API is asynchronous and uses callback functions to track the results of a database query.
Compact usage defining a callback function on the fly might look something like this:

var database = openDatabase("Database Name", "Database Version");

database.executeSql("SELECT * FROM test", function(result1) {
   // do something with the results
   database.executeSql("DROP TABLE test", function(result2) {
     // do some more stuff
     alert("My second database query finished executing!");
   });
});

There will also be a small example of how to use the API in a real site that we’ll try to keep up to date as things evolve.

This initial implementation has some things missing from the spec as well as a few known bugs. But it does the basics and the best way to discover what needs work is to get it out there for people to start using it!

If you find any bugs, would like to suggest features, or have gripes about the spec itself, please drop by #webkit or drop us a line on the WebKit email lists.

Oh, and one more thing…

We’re landing this initial implementation with pretty cool Web Inspector support!
So far you can view the full contents of any table and run arbitrary queries on each database a page is using. We have a lot of ideas for improvements but would also love to hear yours.
DatabaseInspector

Tags: html5, database, storage

MYSQL中EXPLAIN的说明

EXPLAIN列的解释:

  • table:显示这一行的数据是关于哪张表的
  • type:这是重要的列,显示连接使用了何种类型。从最好到最差的连接类型为const、eq_reg、ref、range、indexhe和ALL
  • possible_keys:显示可能应用在这张表中的索引。如果为空,没有可能的索引。可以为相关的域从WHERE语句中选择一个合适的语句
  • key:实际使用的索引。如果为NULL,则没有使用索引。很少的情况下,MYSQL会选择优化不足的索引。这种情况下,可以在SELECT语句 中使用USE INDEX(indexname)来强制使用一个索引或者用IGNORE INDEX(indexname)来强制MYSQL忽略索引
  • key_len:使用的索引的长度。在不损失精确性的情况下,长度越短越好
  • ref:显示索引的哪一列被使用了,如果可能的话,是一个常数
  • rows:MYSQL认为必须检查的用来返回请求数据的行数
  • Extra:关于MYSQL如何解析查询的额外信息。将在表4.3中讨论,但这里可以看到的坏的例子是Using temporary和Using filesort,意思MYSQL根本不能使用索引,结果是检索会很慢

extra列返回的描述的意义

  • Distinct:一旦MYSQL找到了与行相联合匹配的行,就不再搜索了
  • Not exists: MYSQL优化了LEFT JOIN,一旦它找到了匹配LEFT JOIN标准的行,就不再搜索了
  • Range checked for each Record(index map:#):没有找到理想的索引,因此对于从前面表中来的每一个行组合,MYSQL检查使用哪个索引,并用它来从表中返回行。这是使用索引的最慢的连接之一
  • Using filesort: 看到这个的时候,查询就需要优化了。MYSQL需要进行额外的步骤来发现如何对返回的行排序。它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行
  • Using index: 列数据是从仅仅使用了索引中的信息而没有读取实际的行动的表返回的,这发生在对表的全部的请求列都是同一个索引的部分的时候
  • Using temporary 看到这个的时候,查询需要优化了。这里,MYSQL需要创建一个临时表来存储结果,这通常发生在对不同的列集进行ORDER BY上,而不是GROUP BY上
  • Where used 使用了WHERE从句来限制哪些行将与下一张表匹配或者是返回给用户。如果不想返回表中的全部行,并且连接类型ALL或index,这就会发生,或者是查询有问题不同连接类型的解释(按照效率高低的顺序排序)
  • system 表只有一行:system表。这是const连接类型的特殊情况
  • const:表中的一个记录的最大值能够匹配这个查询(索引可以是主键或惟一索引)。因为只有一行,这个值实际就是常数,因为MYSQL先读这个值然后把它当做常数来对待
  • eq_ref:在连接中,MYSQL在查询时,从前面的表中,对每一个记录的联合都从表中读取一个记录,它在查询使用了索引为主键或惟一键的全部时使用
  • ref:这个连接类型只有在查询使用了不是惟一或主键的键或者是这些类型的部分(比如,利用最左边前缀)时发生。对于之前的表的每一个行联合,全部记录都将从表中读出。这个类型严重依赖于根据索引匹配的记录多少—越少越好
  • range:这个连接类型使用索引返回一个范围中的行,比如使用>或<查找东西时发生的情况
  • index: 这个连接类型对前面的表中的每一个记录联合进行完全扫描(比ALL更好,因为索引一般小于表数据)
  • ALL:这个连接类型对于前面的每一个记录联合进行完全扫描,这一般比较糟糕,应该尽量避免

Tags: mysql, database, explain

MySQL 5.0系列新的社区稳定版5.0.75发布!

MySQL 5.0从5.0.27以后,单数版本为社区版。双数版本号为企业版。如果您还不想从5.0升级到5.1的话,可以继续使用5.0的这个版本。主要还是以安全更新和bug fix居多。
官方change-log网址:http://dev.mysql.com/doc/refman/5.0/en/releasenotes-cs-5-0-75.html
简要说明:

Functionality added or changed:

  • Security Enhancement: To enable stricter control over the location from which user-defined functions can be loaded, the plugin_dir system variable has been backported from MySQL 5.1. If the value is non-empty, user-defined function object files can be loaded only from the directory named by this variable. If the value is empty, the behavior that is used prior to the inclusion of plugin_dir applies: The UDF object files must be located in a directory that is searched by your system's dynamic linker. (Bug#37428)

  • Previously, index hints did not work for FULLTEXT searches. Now they work as follows:

    For natural language mode searches, index hints are silently ignored. For example, IGNORE INDEX(i) is ignored with no warning and the index is still used.

    For boolean mode searches, index hints are honored. (Bug#38842)

 

Tags: mysql, database, community

InnoDB数据表空间文件平滑迁移

为了保持作者原有的格式,和他的URL版本的邮箱,我就不做更改了。其实世界上很多事情都是那么巧的,php focus群里的朋友还在问我数据库是否能够直接拷了就能使用。我的解释是4.0以下的版本都可以拷的,从4.1开始尽量使用mysqldump,但是sundj说,对于MYISAM类型的数据库和表,是可以直接COPY的。对于INNODB则不行。然后打开日常订阅的一些RSS,就发现了这篇文章 。。。套用范伟老师的话:缘份呐

原文如下:

作/译者:叶金荣(Email: ),来源:http://imysql.cn,转载请注明作/译者和出处,并且不能用于商业用途,违者必究。

前言

InnoDB存储引擎满足了MVCC和ACID特性,在需要支持事务的环境下必不可少。有些环境下,采用InnoDB可能效果比MyISAM还要来 的好。不过,在很多人眼中看来,InnoDB表空间文件由于无法实现跨服务器平滑迁移,因此不愿意使用。实际情况真是这样吗?本文就来探讨一下 InnoDB表空间文件的平滑迁移可能性。

如何迁移?

从MySQL文档中我们了解到,InnoDB的表空间可以是共享的或独立的。如果是共享表空间,则所有的表空间都放在一个文件 里:ibdata1,ibdata2..ibdataN,这种情况下,目前应该还没办法实现表空间的迁移,除非完全迁移,因此不在本次讨论之列;我们只讨 论独立表空间的情况。

不管是共享还是独立表空间,InnoDB每个数据表的元数据(metadata)总是保存在 ibdata1 这个共享表空间里,因此该文件必不可少,它还可以用来保存各种数据字典等信息。数据字典中,会保存每个数据表的ID号,每次发生数据表空间新增时,都会使 得该ID自增一个值(++1),例如:CREATE TABLE xx ENGINE = InnoDB / ALTER TABLE xx ENGINE = InnoDB 都会使得ID值增加。
有了上面的理解,想要实现InnoDB表空间文件的平滑迁移就很容易了,呵呵。下面是一些例子:
假定我们有2台DB主机,一个是A,一个B;现在想把A上的某个InnoDB表空间文件迁移到B上直接用。

一、迁移失败的例子

直接从A上把表空间文件 yejr.ibd 拷贝到 B 上后,导入表空间,报错,无法使用。这是由于A,B上创建该表时的顺序不一致,导致表的ID不一样,无法导入。
注意:,在这里,表空间文件直接拷贝的前提是该表空间处于"干净"状态下,也就是所有的数据均已经刷新到磁盘中,否则可能导致无法使用或部分数据丢失。
1. 在B上将旧的表空间废弃

(root@imysql.cn/17:52:47)[yejr]>ALTER TABLE yejr DISCARD TABLESPACE;
Query OK, 0 rows affected (0.00 sec)

2. 拷贝到目标机器

scp yejr.ibd B:/home/mysql/yejr/yejr.ibd
....

3. 启用该表空间

(root@imysql.cn/17:52:47)[yejr]>ALTER TABLE yejr IMPORT TABLESPACE;
ERROR 1030 (HY000): Got error -1 from storage engine

4. 查看错误

InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: Error: trying to open a table, but could not
InnoDB: open the tablespace file './test/b.ibd'!
InnoDB: Error: cannot reset lsn's in table `test/b`
InnoDB: in ALTER TABLE ... IMPORT TABLESPACE

5. 很明显,是权限的问题,修正过来,然后重新导入

(root@imysql.cn/17:52:47)[yejr]>ALTER TABLE yejr DISCARD TABLESPACE;
ERROR 1030 (HY000): Got error -1 from storage engine

6. 怎么还是错误?继续看日志

InnoDB: Error: tablespace id in file './yejr/yejr.ibd' is 15, but in the InnoDB
InnoDB: data dictionary it is 13.
InnoDB: Have you moved InnoDB .ibd files around without using the
InnoDB: commands DISCARD TABLESPACE and IMPORT TABLESPACE?
InnoDB: Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/innodb-troubleshooting.html
InnoDB: for how to resolve the issue.
InnoDB: cannot find or open in the database directory the .ibd file of
InnoDB: table `yejr/yejr`
InnoDB: in ALTER TABLE ... IMPORT TABLESPACE

从上面的日志得知,由于在A服务器上,yejr表的ID是15,而在B服务器上,yejr表的ID却是13,二者不一致,因此迁移失败。
既然只是因为ID不一样,而且有了上面的理论基础,我们完全可以人为的让它们的ID一致嘛,请看下面的第2次尝试。

二、人工干预下的成功迁移

1. 上面的例子中,B上面的yejr表ID为13,而A上面为15;因此只需要让B上的yejr表ID增加2就可以了。

(root@imysql.cn/17:52:47)[yejr]>ALTER TABLE yejr RENAME TO yejr1;
Query OK, 0 rows affected (0.00 sec)
#这个时候,yejr的ID变为14
(root@imysql.cn/17:52:47)[yejr]>ALTER TABLE yejr1 RENAME TO yejr;
Query OK, 0 rows affected (0.00 sec)
#这个时候,yejr的ID变为15

2. 然后,我们再导入

(root@imysql.cn/17:52:47)[yejr]>ALTER TABLE yejr IMPORT TABLESPACE;
Query OK, 0 rows affected (0.00 sec)
(root@imysql.cn/17:52:47)[yejr]>select count(*) from yejr;
+----------+
| count(*) |
+----------+
| 3 |
+----------+
1 row in set (0.00 sec)

看到了吧,成功了,呵呵。想要让他ID增加的方式也可以重复创建表,根据实际情况或者个人喜好而定了。
以上测试均在mysql 5.0.67版本下通过,只不过显示数据稍作处理了。

原文URL:http://imysql.cn/2008_12_17_migrate_innodb_tablespace_smoothly

Tags: innodb, mysql, database, 数据迁移, 叶金荣

mysql处理UTC时间

上午莫莫找我,问我有没有办法处理UTC时间,我很得意的将前两天COPY过来的,淘宝DBA的文章发给他看。说道,很简单呀,str_to_date就行了。

然而实现下来,却不正常,莫莫的时间是:05/Dec/2008:12:10:59 +0800,处理了半天都没有处理下来。因为我用的是:

SELECT STR_TO_DATE('05/Dec/2008:12:10:59 +0800' , '%d/%m/%Y');在我想来,date,month,year就行了,结果,返回给我的是NULL,死活不知道是什么问题。。。。

后来莫莫和我说,陌陌解决了这个问题,他用的是:SELECT STR_TO_DATE('05/Dec/2008:12:10:59 +0800' , '%d/%b/%Y');整个参数里就一个b和我的不一样。

才知道,也才明白,用STR_TO_DATE的时候,后面的参数和格式要和前面的参数一模一样,包括位置,包括参数的格式;虽然返回的值是:2008-12-05,但格式不对或者顺序不对,返回的肯定是NULL

记录下来,提醒一下自己,这个东西和php的strtotime不一样啊。。。

Tags: mysql, database, utc, str_to_date

Records:2312345