gOxiA=苏繁=SuFan Blog

 升级 MySQL 数据库
        MySQL 作为一款免费、跨平台的数据库得到众人的青睐，MySQL 对硬件的要求并不高，而且安装非常简便，我们在 Windows 下除了可以使用标准的安装模式进行安装以外，还可以手工进行安装。我个人就非常喜欢手工方式进行安装。而今天的主题主要是与大家分享在如何手工方式升级安装 MySQL，并升级我们的 MySQL 数据库。

        之前我已经提到 MySQL 支持手工方式安装，我们下载到适当的 No Install MySQL 版本后，开始做升级前的准备。首先我们使用服务管理器或通过命令行停止 MySQL 服务，之后进入 MySQL 安装目录下的 bin 子目录执行“mysqld --move”，至此便完成了 MySQL 的卸载！（呵呵，是不是相当简单）我们可以将就版本的 MySQL 目录重新命名。

        之后将下载到的 MySQL 解压缩到指定的目录，如：MySQL，之后将旧版本的数据库拷贝到新版 MySQL 目录下的 Data 子目录中，之后执行“mysqld --install”完成 MySQL 的安装，启动 MySQL。

        MySQL 的升级至此还并未完成，我们还需要对旧的数据库进行更新，为此我们执行 MySQL 目录下 bin 子目录下的“mysql_upgrade.exe”完成数据库的升级，由于执行过程默认 root 密码为空，所以请先将 root@localhost 的密码改为空。

        到这里就完成了整个数据库的升级，此外需要注意的是我们应该在升级 MySQL 的同时更新新版的 my.ini 文件。

        使用 Forefront Client Security 已经有一段时间，感觉使用非常方便，最关键的是主程序短小精悍，不需要频繁的人工干预，更新与 Microsoft Update 集成。
        最近，发现使用 QQ 的时候经常会出现一卡一卡的现象很让人恼火，耽误使用，严重影响了操作体验。拿出测试工具检测硬盘，发现硬盘状况良好，性能指标也就那样了。做了磁盘整理，也重新做过系统总是不能有效解决这个现象。无意中回忆起之前使用 Norton 时也有这样的问题，当时根据网上搜索的解决方法是将 QQ 的聊天信息数据库给排出扫描，难道还是因为这个原因？于是打开 Forefront Client Security 切换到“工具”选项卡，进入“选项”设置，在高级选项中进行文件排出，我们只需要把 msgex.db 给排出掉即可。哈哈，问题解决了！因为 Forefront Client Security 不再频繁扫描 msgex.db 文件，所以 QQ 来信息后的相应速度变快了，不在出现卡停状态。系统的整体相应速度因为不受即时扫描的影响，所以速度也出现了大幅度的提升。之前由于 Thinkpad x60 配置高所以性能下降感觉并不明显也没有往这方面想，在单位又没时间去找原因。

        总之，问题是得到解决了！特与大家分享……

        大家都知道微软发布的 Windows Vista 中包含了一个新的安全技术 - User Account Control（UAC，用户帐户控制），同样该技术也被包含在 Windows Server 2008 中。UAC 到目前为止还是备受争议，但是我个人已经很依赖这个安全特性，而且在实际操作中感觉越来越习惯，前提是 UAC 确实在安全方面起到了一定的作用。而今天提出这个议题的主要原因是因为我的日常工作经常涉及到 B/S 管理以及安全防护，要知道现在的“黑客”通过工具入侵一台没有经过防护措施的服务器是多么的轻而易举，一些 ITPro 们经常要检查系统是否存在新的漏洞，防止这些“黑客”有机可趁。在我所接触上百次的客户服务器安全事件中，70%以上都是由于未对服务器进行安全加固，“黑客”通过“WebShell”对系统进行入侵，之后“黑客”为所欲为，植入后门、木马等等。面对这些安全事件，实在令人头疼！这些客户服务器的运维人员的工作质量令人堪忧……
        微软 Windows Server 2008 已经正式发布，IIS 7 的改进是非常之大，除了性能方面的提升，安全方面也得到了大大的提高。但是没有经过安全加固的 Web Server 同样很容易遭到“黑客”的入侵和破坏，再次同时使我联想到了 UAC  的作用，我一直在设想如果对 用于 Web 服务的 Windows Server 2008 进行了安全加固之后，开启 UAC 岂不是为系统加了把锁，更确切地讲是增加了一道安全防护墙。因为微软公司出于安全因素的原因，在设计 UAC 时并为加入命令行的支持，也就是说我们无法通过命令行来调用或干预 UAC 的操作，这就意味着如果当你通过命令行或使用 WebShell 调用某些命令时，一旦触发 UAC 那么命令结果一定是失败的。相信能避免不少安全事件的发生……
        但是启用 UAC 也存在一些问题，如果一套 B/S 程序中触发了 UAC ，那么也将会被拦截，结果自然是程序运行失败，当然具体的兼容性还需要进行针对性的评估。
        总之，根据我的个人工作经验，我相信对于大多数 Web 程序来说，开启 UAC 并不会对其造成影响，在 Web Server 上，特别是公共主机上开启 UAC 是非常有必要的。
        最后，需要提到的一点是，在之前我已经提到 UAC 不支持命令行的调用及干预，所以在 Server Core 上 UAC 功能是无效的，即使你通过注册表启用了 UAC 功能，但实际上系统并未启用。到目前为止，微软仍未透露是否会在未来支持 UAC 在命令行中的调用及干预，但是从设计初衷来看，这个期望恐怕遥遥无期，一旦支持 UAC 的命令行支持，那等于形同虚设！