当你的 WordPress 网站运行了一个比较长的时间，一般都会在数据库中存在某些垃圾数据，或者在不当的使用中，会导致某些数据库表损坏，这个时候我们就需要对数据库表进行修复和优化。大家比较常用的应该是 phpMyAdmin 内置的优化和修复功能，但是这类工具只能应用于 MyISAM 这个类型的数据表，却无法应用于 InnoDB 数据表。 延伸阅读： MySQL存储引擎MyISAM与InnoDB的优劣 phpMyAdmin教程 之 检查/优化/修复/删除/编辑数据表 其实，WordPress 内置了一个优化和修复数据库的工具，它既可以应用于 MyISAM 数据表，也可以应用于 InnoDB 数据表。要开启这个工具很简单，在网站根目录下的 wp-config.php 文件的“/* 好了！请不要再继续编辑。请保存本文件。使用愉快！ */”前面，添加下面的代码即可： 1 define(’WP_ALLOW_REPAIR’, true); define(‘WP_ALLOW_REPAIR’, true); 然后访问如下地址即可访问到该工具： 1 http://你的域名/wp-admin/maint/repair.php http://你的域名/wp-admin/maint/repair.php 点击相应的按钮即可进行操作，有什么问题都会返回相应的信息给你的。提示：在“修复并优化数据库”时，如果第一次没有生效，请多试几次，有时候需要多次执行才能完成。 重要提示： 1.在操作之前，请务必先手动下载备份好你的数据库，以防万一。 2.在不使用该工具的时候，请将 define(‘WP_ALLOW_REPAIR’, true); 的true 改为 false，或删除这行代码 当然，如果你不想编辑 wp-config.php 添加 define(‘WP_ALLOW_REPAIR’, true); ，你可以安装启用 Enable WP Database Tools 这个插件，它可以自动开启数据库工具。 参考： https://wp-mix.com/wordpress-repair-optimize-innodb/ […]
数据库
WordPress 使用 WP-Sweep 清理和优化数据库
本文目录[隐藏]1WP-Sweep 详细清理功能2WP-Sweep 特点3WP-Sweep 预览4WP-Sweep 下载安装 说到数据库清理优化，大家比较熟知的应该是 WP-Optimize，今天要推荐另一个这方面的插件：WP-Sweep。它可以让你清理WordPress中未用的、孤立的和重复的数据，还可以优化数据库中的表。 WP-Sweep 详细清理功能 修订版本自动草稿已删除的文章未经批准的评论垃圾评论已删除的评论孤立的文章Meta孤立的评论Meta孤立的用户Meta孤立的项目关系未使用的项目重复的文章Meta重复的评论Meta重复的用户MetaTransient 选项优化数据库表文章Meta中的 oEmbed 缓存 WP-Sweep 特点 WP-Sweep 尽可能使用适当的 WordPress 函数来进行清理优化操作，而不是直接使用MySQL查询来操作，所以要安全和稳定很多。 所用到的函数如下： wp_delete_post_revision()wp_delete_post()wp_delete_comment()delete_post_meta()delete_comment_meta()delete_user_meta()wp_remove_object_terms()wp_delete_term()delete_transient()delete_site_transient() WP-Sweep 预览 安装启用 WP-Sweep 后，可以在 工具 – 清扫 进入操作界面： WP-Sweep 下载安装 在后台插件安装界面搜索 WP-Sweep 即可在线安装，或者在这里下载 WP-Sweep 已经汉化该插件，并提交语言包给作者，如果你等不及，可以在这里下载简体中文包，解压后上传到该插件下的 languages 目录即可。 特别提示： 1.插件的清扫操作是不可逆的，在进行操作前，请务必备份你的数据库，以防万一！ 2.有些数据可能是未发布的草稿文件的，在清扫前，请尽量确保在没有草稿的情况下操作！
WordPress 导入数据库报错 Unknown collation: utf8mb4_unicode_520_ci 的解决办法
今天将一个数据库导入到本地环境时，提示 #1273 – Unknown collation: ‘utf8mb4_unicode_520_ci’ 错误，具体如下图所示： 原因是数据库版本差异，导致wordpress数据库的编码整理方式不一样。MySQL 5.6 以及以上版本下，安装 WordPress 4.6 及以上版本的时候，默认的编码整理方式为 utf8mb4_unicode_520_ci，但是 MySQL 5.5 及以下版本的数据库，不支持 utf8mb4_unicode_520_ci，所以无法导入。 处理的办法，就是使用 sublime text 等代码编辑器，打开 .sql 数据库，然后批量查找替换所有的 utf8mb4_unicode_520_ci 为 utf8mb4_unicode_ci ，保存后上传即可。
WordPress 数据库探究 #8 — wp_links 和 wp_link2cat
wp_links 通常 wp_links 表使用来存储 blogroll — 网站链接列表。到 blogroll 管理界面，你会看到很多选项，一般的 WordPress 用户都不会用到这些（这里没有经过严格的统计）。所有这些链接选项都是被存储在 wp_links 表征。实际上，你不需要写太多的代码就能把 WordPress 转变成一个链接目录，和曾经的 Yahoo 一样，他所需的只是一个适当的主题。 一个需要注意的地方是每个链接的 link_owner 都保存了。所以你可以知道，谁创建了链接。 wp_link2cat wp_link2cat 数据表是 wp_post2cat 的一个拷贝，除了它是保存链接的 ID 而不是日志的 ID。 这就是所有关于 WordPress 数库结构的介绍。如果你在你的 WordPress 看到其他表，那肯定安装的某一个插件增加的。 以后的文章会介绍 WP 2.3 增加的新表。 标签：WordPress 数据库
WordPress 数据库探究 #7 — wp_categories 和 wp_post2cat
wp_categories 如果你的 WordPress 有分类，那么 wp_categories 就是用来保存这些记录的数据表，分类名和描述都保存在那里，还有 ID 和每个分类的父级分类。 为了能运行得更快，WordPress 经常在数据库保存一些累计的值，而不是每次用到的时候才计算。举个例子，经常会被请求的在每个分类下的日志或者链接数目都会简单的存储在 wp_categories 表中（WordPress 对日志和链接使用同样的分类集合）。每次增加一篇日志到分类中，日志计数器（字段 category_counter）就会增加。同样每次从分类中移除日志，该计数器就会减小。对于链接也是一样的（字段 link_count）。就是为什么要在这个表中使用这些额外字段的原因。 wp_post2cat 把日日志链到分类是通过 wp_post2cat 这个数据表实现的。这是关系数据库中多对多关系的标准实现。wp_post2cat 表只有三个字段：唯一的 ID（自动产生），日志的 ID，和这篇日志所属分类的 ID。 下一篇介绍最后两个表：wp_links 和 wp_link2cat 标签：WordPress 数据库
WordPress 数据库探究 #6 — wp_options
wp_options 是用来存储 WordPress 中所有全局选项的数据表。这个表的核心和 wp_postmeta 和 wp_usermeta 这两个表是非常相似的，并且这个表是非常容易理解的 — wp_options 存储了 WordPress 所有信息，这和 wp_postmeta 存储日志信息和 wp_usermeta 存储用户信息的用法是一样的。然而你可能注意到它有一些额外的字段。 有个 blog_id 字段，但是它并不用在独立安装的 WordPress 博客中使用。它只在 WordPress MU 中使用。常规的 WordPress 和 WordPress MU 的大部分呢源代码和数据的结构很多是相似的。所以 WordPress MU 使用 wp_options 这个表中的 blog_id 这个字段来区分同个 WordPress MU 下不同博客的选项设置。 autoload 这个字段用来控制是否选项总是被 WordPress 或者插件导入并缓存来使用或者是否只是在要求的情况下才被导入。 我观察到很多的选项是自动导入的。 下一篇介绍 wp_categories 和 wp_post2cat 这两个表。 标签：WordPress 数据库
WordPress 数据库探究 #5 — wp_comments
wp_comments 表保存你站点上所有的留言，包括所有通过验证的留言，等待审核的留言，垃圾留言和从 其他文章发送过来的 trackbacks 和 pingbacks。我想不需要我告诉你，你就能猜出这个数据表中大部分字段的意思，但是为了以防万一，我列出你可能关心的： comment_ID — 每条留言的唯一 ID，由 MySQL 自动产生 comment_post_ID — 留言所属日志的 ID comment_author — 留言者的名字 comment_author_email — 留言者的 email comment_author_url — 留言者的 URL comment_author_IP — 留言者的 IP comment_date — 留言的日期和时间 comment_content — 留言的内容 comment_approved — 留言是否已经通过审核 comment_agent — 留言者的浏览器信息 （如：MSIE，Firefox，Safari 等等） comment_type — 是否这是条正常的留言，或者 trackback , 或者其他东东 user_id — 如果留言者是博客的注册用户，这里就是它的ID 这个表中还有其他的一些字段，这里就不一一细讲了。 […]
WordPress 数据库探究 #4 — wp_users 和 wp_usermeta
wp_users WordPress 使用这个数据表存储已注册的用户。用户，登录，加密的密码，全名，注册日期等等资料都会保存到 wp_users 表中。总之是它认为必要的信息用户。 wp_usermeta 就像 wp_postmeta 数据表是为日志准备的，wp_usermeta 数据表是为用户准备的。可以用它保存注册用户的所有信息 — 个人博客设置（举个例子，如个人可视化编辑器喜好设置），生日，联系信息等等。 下一篇将探讨 wp_comments 表 标签：WordPress 数据库
WordPress 数据库探究 #8 — wp_links 和 wp_link2cat
wp_links 通常 wp_links 表使用来存储 blogroll — 网站链接列表。到 blogroll 管理界面，你会看到很多选项，一般的 WordPress 用户都不会用到这些（这里没有经过严格的统计）。所有这些链接选项都是被存储在 wp_links 表征。实际上，你不需要写太多的代码就能把 WordPress 转变成一个链接目录，和曾经的 Yahoo 一样，他所需的只是一个适当的主题。 一个需要注意的地方是每个链接的 link_owner 都保存了。所以你可以知道，谁创建了链接。 wp_link2cat wp_link2cat 数据表是 wp_post2cat 的一个拷贝，除了它是保存链接的 ID 而不是日志的 ID。 这就是所有关于 WordPress 数库结构的介绍。如果你在你的 WordPress 看到其他表，那肯定安装的某一个插件增加的。 以后的文章会介绍 WP 2.3 增加的新表。 标签：WordPress 数据库
WordPress 数据库探究 #7 — wp_categories 和 wp_post2cat
wp_categories 如果你的 WordPress 有分类，那么 wp_categories 就是用来保存这些记录的数据表，分类名和描述都保存在那里，还有 ID 和每个分类的父级分类。 为了能运行得更快，WordPress 经常在数据库保存一些累计的值，而不是每次用到的时候才计算。举个例子，经常会被请求的在每个分类下的日志或者链接数目都会简单的存储在 wp_categories 表中（WordPress 对日志和链接使用同样的分类集合）。每次增加一篇日志到分类中，日志计数器（字段 category_counter）就会增加。同样每次从分类中移除日志，该计数器就会减小。对于链接也是一样的（字段 link_count）。就是为什么要在这个表中使用这些额外字段的原因。 wp_post2cat 把日日志链到分类是通过 wp_post2cat 这个数据表实现的。这是关系数据库中多对多关系的标准实现。wp_post2cat 表只有三个字段：唯一的 ID（自动产生），日志的 ID，和这篇日志所属分类的 ID。 下一篇介绍最后两个表：wp_links 和 wp_link2cat 标签：WordPress 数据库
WordPress 数据库探究 #6 — wp_options
wp_options 是用来存储 WordPress 中所有全局选项的数据表。这个表的核心和 wp_postmeta 和 wp_usermeta 这两个表是非常相似的，并且这个表是非常容易理解的 — wp_options 存储了 WordPress 所有信息，这和 wp_postmeta 存储日志信息和 wp_usermeta 存储用户信息的用法是一样的。然而你可能注意到它有一些额外的字段。 有个 blog_id 字段，但是它并不用在独立安装的 WordPress 博客中使用。它只在 WordPress MU 中使用。常规的 WordPress 和 WordPress MU 的大部分呢源代码和数据的结构很多是相似的。所以 WordPress MU 使用 wp_options 这个表中的 blog_id 这个字段来区分同个 WordPress MU 下不同博客的选项设置。 autoload 这个字段用来控制是否选项总是被 WordPress 或者插件导入并缓存来使用或者是否只是在要求的情况下才被导入。 我观察到很多的选项是自动导入的。 下一篇介绍 wp_categories 和 wp_post2cat 这两个表。 标签：WordPress 数据库
WordPress 数据库探究 #5 — wp_comments
wp_comments 表保存你站点上所有的留言，包括所有通过验证的留言，等待审核的留言，垃圾留言和从 其他文章发送过来的 trackbacks 和 pingbacks。我想不需要我告诉你，你就能猜出这个数据表中大部分字段的意思，但是为了以防万一，我列出你可能关心的： comment_ID — 每条留言的唯一 ID，由 MySQL 自动产生 comment_post_ID — 留言所属日志的 ID comment_author — 留言者的名字 comment_author_email — 留言者的 email comment_author_url — 留言者的 URL comment_author_IP — 留言者的 IP comment_date — 留言的日期和时间 comment_content — 留言的内容 comment_approved — 留言是否已经通过审核 comment_agent — 留言者的浏览器信息 （如：MSIE，Firefox，Safari 等等） comment_type — 是否这是条正常的留言，或者 trackback , 或者其他东东 user_id — 如果留言者是博客的注册用户，这里就是它的ID 这个表中还有其他的一些字段，这里就不一一细讲了。 […]
WordPress 数据库探究 #4 — wp_users 和 wp_usermeta
wp_users WordPress 使用这个数据表存储已注册的用户。用户，登录，加密的密码，全名，注册日期等等资料都会保存到 wp_users 表中。总之是它认为必要的信息用户。 wp_usermeta 就像 wp_postmeta 数据表是为日志准备的，wp_usermeta 数据表是为用户准备的。可以用它保存注册用户的所有信息 — 个人博客设置（举个例子，如个人可视化编辑器喜好设置），生日，联系信息等等。 下一篇将探讨 wp_comments 表 标签：WordPress 数据库
WordPress 数据库探究 #3 — wp_postmeta
可能有很多东西你想保存到你的一些日志中 — 你写日志时候的心情 ，你当时听的歌曲，你所处的地理位置，一些相关日志的列表，特定为搜索引擎指定日志信息等等。所以这些东西都会保存到 wp_postmeta 这个表中。 这个表的结构是非常简单和灵活的。它只有四个字段：meta_id，post_id，meta_key 和 meta_value。meta_id 是自动产生的，我想没有任何情况下你需要去修改它 — 有更多有趣的事情可以去做 。post_id 是当前 meta 信息链到日志的 ID（来自 wp_posts 表的记录）。 meta_key 是你想附加到日志上信息的描述（如 ‘mood（心情）’ 或者 ’song（歌曲）’）。 meta_value 是 meta 信息的实际内容（如 ‘Grumpy!’ 或者 ‘The WordPress Song.mp3′）。 WordPress 使用这个表去存储附件的额外信息，这些信息不适合 wp_posts 表（附件的路径，缩略图信息，等等）。另外，这个表还可以用来存储自定义字段（custom field）的名字和值 — 你可以在日志编辑器下面看到自定义字段框。并且，当然，很多大量插件可以利用这个表。所以，如果你决定在你制作的插件使用这个表，务必为你的 meta 健使用一些唯一的名字。否则，你的插件可能妨碍其他的插件，并且你得到怪异的和完全不可预料的结果。 下一篇是和用户有关的两个表：wp_users 和 wp_usermeta 标签：WordPress 数据库
WordPress 数据库探究 #2 — wp_posts
WordPress 主要被用作一个博客引擎的内容管理系统（简称 CMS）。所以我认为这个“内容”表是最重要的。静态页面，日志和附件都是内容，WordPress 把它们都放在一个表中 — wp_posts。 实际上，附件是被保存在它们原来的位置 — 在磁盘的文件，但是 WordPress 用 wp_posts 表保存附件的元信息，如上传该附件用户的 ID，附件所属日志的 ID，上传的日期等等。 静态页面，日志和附件可以很相似，也可以很不同。现在，我们要看到在它们之间的共同之处。他们都有一个唯一的 ID（通常是 WordPress 或者 MySQL 自动产生的），一个作者（写日志或者上传文件的人），发布日期，题目和秒速（甚至空的，依然有方法日后增加和使用）。它们都有 URL。所以对于每个日志，静态页面和附件，WordPress 把它们存储为 wp_posts 表中的一条数据。 还是一些区分日志，静态页面和附件的方法，为了区分它们，WordPress 使用了 wp_posts 表中的字段 post_type。对于日志，post_type 的值是 ‘post’。对于静态页面 — ‘page’。对于附件 — ‘attachment’。 然后，有些字段简单日志是特殊类型的时候使用。举个例子，字段 post_mime_type 用来存储附件文件类型，如 ‘image/jpeg’ 和 ‘application/pdf’（在 Wikipedia 定义为 MIME ）。 字段 menu_order 用来指定静态页面的顺序。字段 post_parent 用来组织静态页面和子页面之间的关系，同样也用作把附件链到日志。 为了得到每个字段是怎们和什么时候使用的更好的图像，看一下每种类型日志的一条真是记录： SELECT * FROM […]
WordPress 数据库探究 #1 — 介绍
这个系列教程翻译自：A look inside the WordPress database。由于原文比较长，我把它分成一系列教程，今天第一篇是开篇介绍。 WordPress 和其他现代内容管理系统 (CMS) 一样，它是以数据库为中心的程序。它把所有信息都保存到数据中 — 博客设置，日志，评论，链接，用户等等。所以理解数据库是怎么组织是非常重要的，如存储的是什么是数据类型，数据表之间是链接有什么不同。 在我们深入研究之前，我需要强调三点： WordPress API 提供了很多操作数据库的方法而不用直接访问数据库而不用直接访问数据库。所以，从技术层面上说，你不需要知道数据库是怎么组织的。但是如果你知道，你可能在遇到问题的时候能更快找到解决方案，而且更容易实现。 WordPress 数据库模式是小巧而简单的。所以没有什么好怕的。它只有10个数据表，而且每个都只有一些字段。总的来说，它的模式是非常有意义的。它能使你在几秒之后就能记住大部分，尽管你没有必要这样做。 WordPress 数据库模式是有非常详细文档描述的。WordPress Codex 文档以字母顺序解释了数据表，这个在查找东西的时候是有帮助的。但是对于初次使用，最好有不同的顺序，这也是这系列日志尝试做到的。 在这接下来的日志，你可能在另外的浏览器标签页中打开前面提到的 WordPress Codex 中的数据库描述，或者数据库工具，如 PHPMyAdmin 或者 MySQL 命令行。你可以通过运行 “SHOW TABLES” 查询列出 数据库表名列表，可以通过 EXPLAIN 这个命令得到表的详细描述，如：“EXPLAIN wp_posts“。 好的，那我们首先看看 WordPress 默认安装之后有哪些数据表： wp_posts wp_postmeta wp_users 和 wp_usermeta wp_comments wp_options wp_categories 和 wp_post2cat wp_links 和wp_link2cat 这篇到此为止，下一篇我们将给给大家详细介绍 wp_posts 这个表。 […]
更改 WordPress 数据库表名前缀
众所周知，WordPress 在安装时候可以选择表名前缀以在同一数据库安装多个WordPress 程序。但是很多空间商，尤其是老外的虚拟主机商 允许建立多个数据库，这样为了便于管理，很多人在安装多个WordPress 程序的时候选择多个数据库而不是修改表名前缀，当然这样的方式也是被提倡的。 所谓天有不测风云，人有旦夕祸福。如若碰到多个数据库合为单个数据库的时候，头疼事情就来了，这种情况往往在从国外往国内搬的时候，国内空间商不知道为何如此吝啬 既然碰到这种情况，自然修改表名了，或者新建一个WordPress 用WordPress eXtended RSS导入（manage – export），不过这不是这里要讨论的了 更改 WordPress 数据库表名前缀步骤： 禁用所有插件，然后通过 phpmyadmin 备份你的 WordPress 数据库。 用文本编辑器打开你备份的数据库文件(*.sql)，查找“wp_”，并用你准备用的表明比如“Bssn_”替换。 使用 phpmyadmin 将你当前数据库 WordPress 表删除。 导入你刚才修改了的备份文件。 修改wp-config.php文件，将$table_prefix = ‘wp_’; 改为 $table_prefix = ’Bssn_’; 到后台开启所有插件。（如果备份之前没有禁用插件，可能会导致插件工作不正常，到插件管理重新开启即可。） 顺便提一下修改表名前缀的sql语句为： ALTER TABLE wp_bssn RENAME TO bssn_bssn 此句将把 wp_bssn 表更名为 bssn_bssn。 标签：WordPress 数据库
WordPress 技巧：如何修改 WordPress 数据库前缀
我们知道 WordPress 的数据库表，可以设置前缀，默认是 wp_，很多同学也就默认用了 wp_，如果某种原因（比如提高安全性）要修改的 WordPress 数据的前缀，我们应该怎么做？ 开始之前 修改数据是一件风险很高的工作，开始之前必然就是做好数据库备份，也可以把博客设置为维护状态。 在 wp-config.php 修改数据库前缀 打开你的 wp-config.php 文件，把数据库前缀 wp_ 改成你想要的前缀，比如 wpjam_。 $table_prefix = ‘wpjam_’; 修改数据表名字 打开 PHPMySQL，找到你的数据库，然后执行以下 SQL，把所有数据库表前缀从 wp_ 改成 wpjam_。 RENAME table `wp_commentmeta` TO `wpjam_commentmeta`; RENAME table `wp_comments` TO `wpjam_comments`; RENAME table `wp_links` TO `wpjam_links`; RENAME table `wp_options` TO `wpjam_options`; RENAME table `wp_postmeta` TO `wpjam_postmeta`; RENAME table […]
使用 SSH 导入和导出数据库
一般我们是使用 PHPMyAdmin 进行数据库的操作，但是 PHPMyAdmin 是基于 PHP 构建的一个程序，对文件的大小有限制，而有时我们的数据库又特别大，怎么办呢？其实我们还可以通过 SSH 进行数据库导入和导出的操作。 使用 SSH 导出数据库 mysqldump -u 数据库用户名 -p 数据库密码 –add-drop-table –complete-insert 数据库名 | gzip > db_wpjam.sql.gz 导出数据库为 db_wpjam.sql.gz 使用 SSH 导入数据库 先把 db_wpjam.sql.gz 解压缩： gzip -d db_wpjam.sql.gz 然后导入： mysql -u 数据库用户名 -p 数据库密码 数据库名 < db_wpjam.sql.gz –default-character-set=utf8 标签：SSH WordPress 数据库
Optimize DB：在 WordPress 后台优化 MySQL 数据库
为什么需要优化数据库 随着 MySQL 的使用，包括 BLOB 和 VARCHAR 字节的表将变得比较繁冗，因为这些字段长度不同，对记录进行插入、更新或删除时，会占有不同大小的空间，记录就会变成碎片，且留下空闲的空间。就像具有碎片的磁盘，会降低性能，需要整理，因此要优化。 如何优化 WordPress 数据库 而 WordPress 使用的数据库正是 MySQL，所以当你觉得 WordPress 速度比较慢的时候，对 MySQL 进行优化下，可以相当程度上提高 WordPress 的速度。我们可以通过 PHPMyAdamin 对 MySQL 表进行优化： 在 PHPMyAdmin 优化 MySQL 表 使用 Optimize DB 插件在WordPress 后台直接优化 MySQL 数据库 但是如果每次都要进入 PHPMyAdmin 优化 MySQL表，这样是非常麻烦的，今天推荐的插件：Optimize DB 就能让你在 WordPress 后台直接优化 MySQL 数据表。 该插件安装非常简单，上传激活即可，激活之后，在 WordPress 后台 > 工具（Tools） > Optimize DB […]
WordPress 数据库维护时常用到 12 个 SQL 语句
虽然通过 WordPress 强大的插件库，你几乎可以干任何的事情，但是有时候需要快速修复一些特定的问题的时候，直接操作数据库可能反而是方便的方法，所以这篇文章就给大家介绍 WordPress 数据库维护时常用到 12 个 SQL 语句。 *注：下面假设 WordPress 数据库的表的前缀都是默认的“wp_”。 1. 直接在数据库中修改密码 密码忘记了是经常的事情，博客密码忘记了进不去，可以直接在数据库里面修改： UPDATE wp_users SET user_pass = MD5(‘PASSWORD’) WHERE user_login = ‘admin’ 上面采用了 MySQL 的 MD5() 函数讲密码转成 MD5 Hash。 2. 将日志从一个作者转移到另外一个 假如你的博客的某个作者离开了，或者你不想让“admin”作为作者名，想把日志的作者从一个改到另外一个： UPDATE wp_posts SET post_author=NEW_AUTHOR_ID WHERE post_author=OLD_AUTHOR_ID; *注：你需要知道两个作者的 user id。 3. 删除数据库中日志修订记录和其相关的 post_meta 数据 特别是针对多人博客的时候，日志修订功能很重要，但是日志修订功能也在数据库里面添加了很多的数据，假设你的博客只有 100 篇日志，每篇日志有 10 个日志修订，你的 posts 表中就会有超过 […]
优化 WordPress 数据库，提高 WordPress 速度
WordPress 的机制是主要使用 wp_posts 表来存储所有数据，包括日志，页面，附件，导航菜单等等，所以 WordPress 使用了一定时间之后，数据量一大还是有点慢，除了对 WordPress 进行全方面的优化之外，我们还可以对数据表进行减肥和优化，来提高 WordPress 的速度。 1. 删除所有日志修订 日志修订是所有速度慢的罪恶之源，几百篇日志会有几千条日志修订的记录，所以用力删除把，提速效果非常明显： DELETE a,b,c FROM wp_posts a LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id) LEFT JOIN wp_postmeta c ON (a.ID = c.post_id) WHERE a.post_type = ‘revision’ 2. 关闭日志修订 日志修订不是好东西，你可以关闭它或者限制数据库存的修订个数： 关闭日志修订： define(‘WP_POST_REVISIONS’, false); 限制日志修订为最新的3个： define(‘WP_POST_REVISIONS’, 3); 3. 优化 wp_posts 表 对 MySQL 数据记录进行插入、更新或删除时，会占有不同大小的空间，记录就会变成碎片，且留下空闲的空间。就像具有碎片的磁盘，会降低性能，需要整理，因此要优化。 OPTIMIZE […]
使用 phpMyAdmin 管理 WordPress 数据库
phpMyAdmin 是开源的 MySQL 数据库管理工具，它能够让用户直接对 MySQL 数据库进行操作的 PHP 脚本程序。 什么是 phpMyAdmin？ phpMyAdmin 是用来对数据库进行各种操作的维护数据表，备份信息，和在 WordPress 不工作的情况下直接编辑数据库。 其实 phpMyAdmin 最大的好处就是可以直接用来进行 SQL 查询，这比直接使用 MySQL 的命令行方便了很多。 一般在主机的控制面板，如 cPanel 和 Plesk 中，都已经预装了 phpMyAdmin。如果你使用这些主机控制面板，无需做任何事情的时候，只需在控制面板中找到相应的链接即可使用 phpMyAdmin。当然也可以也可以直接到 phpMyAdmin 项目页面下载和安装即可。 在 WordPress 后台使用 phpMyAdmin WordPress 也是使用 MySQL 作为数据库构建的，它把所有信息都保存在 MySQL 数据库中的，所以我们可以通过 phpMyAdmin 来查看 WordPress 的数据库中数据，字段和表。如果为了方便，也可以使用 WP-phpMyAdmin 这个插件可以整合 phpMyAdmin 到 WordPress 后台。 WP-phpMyAdmin 这个插件使用非常简单，只需要下载安装激活即可，然后到 WordPress 后台 > […]
Android数据库SQLite使用方法 Android开发技术
大多数过去做MIS或OA系统的可能都很熟悉数据库相关的操作，Android平台和Windows Mobile一样都支持本地的SQL数据处理，这点Android使用了比MySQL嵌入版更轻量级的SQLite，Google有关Android数据操作的方法提供一个高层的封装就是ContentProvider。一组数据操作可以使用ContentValues对象来完成度或写，ContentValues提供了put和get两种方法分别对应设置和读取，如果对于原始SQL语法比较了解还是建议使用更为灵活的raw执行语言比较快。 主要注意的是Android中使用的SQLite受数据库版本因素而限制，SQLiteDatabase是原始的数据库操作类，提供了createDatabase方法来创建一个新的数据库，最终保存为.db格式的文件，而已经存在的数据可以使用openDatabase方法直接打开，使用execSQL方法可以直接执行SQL语句，完成插入、更新、删除等等，而查询也可以使用本地的SQL语句直接完成，使用rawQuery方法即可，这样会返回一个Cursor对象，我们直接遍历Cursor使用movetoFisrt和movetoNext方法进行遍历查询。直接使用getString或getInt等方法获取每列的数据即可。 而ContentProvider方式比较简单，大家直接看Android SDK中的NoteList例子就很好理解了。
