有什么（最好是开源的）软件可以分析一个PostgreSQL的EXPLAIN，并推荐必要的索引，以加快查询？
所以我有一个运行Outlook 2007的Windows XP SP 3机器。当我在Outlook中search一个使用基本关键字（比如说“MySQL”）存在的电子邮件时，我得不到任何结果。 但是，Outlook给我以下消息： search结果可能不完整，因为项目仍在编制索引。 点击这里了解更多详情。 当我点击时，我得到以下内容： Outlook目前正在索引您的项目。 search结果可能不完整，因为项目仍在编制索引。 “邮箱 – 用户”中剩余8783项 所有打开的邮箱中剩余8812个项目。 问题是，这些数据是几天来的报告数，而且outlook一天8小时。 它似乎并不像指数工作。 据我所知，这个指数在3个星期前似乎停了下来。 如何强制Outlook 2007重新索引所有内容并重新开始正常工作？
如何重新扫描我的驱动器，使我的“search工具”能够在我的系统上find一个新的文件？ 我正在search如何启动一个索引/扫描命令到这个应用程序的任何困难时间。 我主要使用：“查找”和“定位”，但认为这是一个好主意，知道其他search应用程序及其索引/扫描命令（对不起，不知道最好叫它：索引或扫描扫描系统上的新文件） 。 我的问题：我安装或下载一个新的文件到系统，但不知道在哪里。 我的需要：扫描我的驱动器（最好通过文件夹，但我愿意与全面扫描生活） 我的操作系统： Linux Debian（Lenny） 谢谢！
所以，我在我的机器上安装了MySQL，并且需要更改MySQL将索引的最大字长ft_max_word_len 。 但是，当我通过提供的工具进行设置并查询它时，仍将其列为最大84（我需要128+）。 当我尝试使用命令行时，我得到以下内容： C:\>mysqld –ft_max_word_len=128 111210 23:55:46 [Warning] option 'ft_max_word_len': unsigned value 256 adjusted to 84 111210 23:55:46 [Warning] option 'ft_max_word_len': unsigned value 128 adjusted to 84 应该指出的是，我试图在GUI工具中将其更改为256，所以这可能是价值来自哪里。 但是，为什么我会得到这两个，为什么我不能调整这个值？ 值得注意的是，我在Windows 7上，MySQL 5.1.41在64位上。 更新：从@ thinice的评论，这使我相信，这是MySQL中的一个错误（从它的声音是一个大多数没有logging的，我将需要改变）。 所以也许我的问题是，有没有人有任何改变这个价值的暗示？
你将使用什么工具来validation恢复的文件结构是完整的和完整的？ 我的环境是Windows Server 2008文件服务器。 （我们使用磁带进行备份，但这是不重要的。） 我正在寻找一个工具，将会： logging指定目录下的所有文件和文件夹的名称 可以计算每个遇到的文件的校验和 以可读的格式保存此索引 比较索引与恢复的数据并显示差异 一些背景：我最近不得不更换我们的文件服务器中的磁盘。 升级计划在最近一次完整备份后的36小时开始，因此我创build了差异备份。 但事实certificate，我们的一个应用程序正在清除保存在服务器上的文件的存档位，所以这些文件不包含在差异备份中。 我没有意识到这一点，直到我的用户报告一些文件丢失。 除此之外，是否还有其他常用方法来validation还原的完整性 ？ 我经常被告知，通过恢复备份来testing备份是了解备份正常工作的唯一方法，但是如何处理99％正常工作的情况以及另外1％的静默失败？ 更新：显然我需要澄清一些事情。 我已经尽可能使用完全备份，但有时情况需要差异备份。 发生这种情况时，我需要validation原始数据中的每个文件是否还在恢复的数据中。 我已经在使用Backup Exec中的“validation”function，但只能确保写入磁带的所有内容都能被读回。 我确实进行了偶尔的抽查检查，以确保备份媒体完好无损。 我已经熟悉“testing备份的最佳方法是恢复备份”的常识。 这是一个必要的步骤，但这还不够。 能够恢复您备份的文件并不能保证您所需要的所有文件都是首先备份的。 这是我需要解决的问题。
我有一个大的表，它有一个带有标识主键的聚集索引。 我正在决定这个表的填充因子的正确值，以尽量减less页面拆分。 我们使用脚本每日运行测量碎片并采取适当的行动来维护索引。 该表包含可变长度的列。 我的第一个想法是把它设置为100（因为logging应该只写在表的末尾），但是我认为对可变长度列的更改也会导致页面拆分，所以现在我正在向90度转移。 任何意见赞赏。
我有一张有14亿logging的桌子。 表结构如下： CREATE TABLE text_page ( text VARCHAR(255), page_id INT UNSIGNED ) ENGINE=MYISAM DEFAULT CHARSET=ascii 要求是为列text创build一个索引。 桌子大小约为34G。 我试图通过以下声明创build索引： ALTER TABLE text_page ADD KEY ix_text (text) 经过10个小时的等待，我终于放弃了这个方法。 这个问题有没有可行的解决办法？ 更新 ：表不太可能被更新或插入或删除。 在列text上创build索引的原因是因为这种sql查询会频繁执行： SELECT page_id FROM text_page WHERE text = ? 更新 ：我通过分区表解决了这个问题。 该表格被分成40个栏目text 。 然后在桌子上创build索引需要大约1个小时才能完成。 当表格大小变得非常大时，似乎MySQL索引创build变得非常慢。 分区将表格缩小为更小的中继。
如果您在mysql INNODB表中禁用了键（挂起索引），那么这个设置最后会持续多久？ 对于像这样的查询： ALTER TABLE users DISABLE KEYS; 在脚本的末尾重新启用密钥？ 或者他们持续到你明确地转动索引？
我们每晚的完整（和周期性差异）备份正在变得相当大，主要是由于我们桌上的索引数量太多; 大约一半的备份大小是由索引组成的。 我们正在使用简单恢复模式进行备份。 有没有办法通过使用FileGroups或其他文件分区方法从备份中排除索引？ 如果这可以扩展到全文目录，这将是很好的。