小编Kev*_*Kev的帖子

当我对INSERT具有一AUTO_INCREMENT列的表执行单行时，我想使用该LAST_INSERT_ID()函数返回AUTO_INCREMENT为该行存储的新'ed 值。

许多 Microsoft SQL Server 开发人员和管理员无疑都知道 SQL Server（SCOPE_IDENTITY和@@IDENTITY）中的等效功能并非没有问题。

我知道 MySQL 文档状态：

生成的 ID 基于每个连接在服务器中维护。这意味着函数返回给给定客户端的AUTO_INCREMENT值是为该客户端影响AUTO_INCREMENT列的最新语句生成的第一个值。即使其他客户端生成AUTO_INCREMENT自己的值，该值也不会受到其他客户端的影响。此行为可确保每个客户端都可以检索自己的 ID，而无需关心其他客户端的活动，也无需锁定或事务。

（来源）

甚至说：

同时使用来自多个客户端的LAST_INSERT_ID()和AUTO_INCREMENT列是完全有效的。

（来源）

是否存在任何可能导致LAST_INSERT_ID()不返回正确值的已知风险或场景？

我在 CentOS 5.5 x64 和 Fedora 16 x64 以及 InnoDB 引擎上使用 MySQL 5.5。

这篇 Microsoft 文章 -如何确定 64 位版本的 Windows Server 2008 和/或 Windows 2008 R2 的适当页面文件大小提供了计算 64 位 Windows 2008 和 Windows 2008R2 的页面文件大小的指南。这无疑适用于通用服务器。我想知道在 Windows 2008/R2 64 位上运行的 SQL Server 2008R2 的指导是什么？

我假设我们希望内存中的数据尽可能少地访问页面文件，否则 SQL 可能会访问磁盘两次以获取数据。SQL Server 甚至允许内存中的数据访问页面文件吗？我已经通过SQL Server 2008 R2 联机丛书寻找指导，但还没有发现任何关于页面文件使用的提及。

这是一个潜在的使用场景：给定一个具有 64GB RAM 的物理服务器，整个 64GB RAM 是否需要一个页面文件？我们应该为 96GB 的页面文件做好准备吗？对于单个文件来说，这似乎有点过分。我知道传统观点是，Windows 将页面文件与内存结合起来，以尝试在 RAM 上更轻松地交换应用程序，但这是真的吗？小于 64GB 的页面文件会影响性能吗？

自从它设置以来，我第一次需要重新启动只读的 MySQL 复制从属设备。

我找到了这篇关于关闭从属设备进行维护的文章（尽管他只是在描述停止mysql守护进程）：

如何安全地[原文如此] 重新启动您的 MySQL 从属服务器

概括起来，程序是：

在mysql客户端：

STOP SLAVE;
FLUSH TABLES;

从操作系统：

/etc/init.d/mysql stop

我会在此时重新启动，然后在系统启动后：

在mysql客户端（mysql守护进程被配置为在启动时启动）：

START SLAVE;

这看起来对吗？还有什么我应该做的吗？

我们在某些服务器上的几乎所有数据库都不需要完全恢复模型（我们不进行事务日志备份），并且默认设置应该始终是创建数据库并指定简单恢复模型。

很多时候，出于某些实际原因，许多数据库是使用 SSMS 创建的。然而，可能会犯错误，操作员可能会忘记指定简单恢复模型。几天后，当由于三四个 60GB 的日志文件从未被截断而使盒子在磁盘空间上挣扎时，这会导致“意外”。

通过在model数据库上配置恢复模型，我可以使简单恢复模型成为新数据库的默认设置。但是，这是推荐的，如果我这样做，它会在将来以任何方式回来咬我吗？

如果我这样做，CAST(1 AS SIGNED INTEGER)我总是最终得到BIGINT退货，例如：

$ mysql -u root -p --column-type-info
Enter password:

--- Copyright and help message snipped for brevity ---

mysql> select cast(1 as signed integer);
Field   1:  `cast(1 as signed integer)`
Catalog:    `def`
Database:   ``
Table:      ``
Org_table:  ``
Type:       LONGLONG            <== LONGLONG i.e. 64 bit integer
Collation:  binary (63)
Length:     1
Max_length: 1
Decimals:   0
Flags:      NOT_NULL BINARY NUM


+---------------------------+
| cast(1 as signed integer) |
+---------------------------+
|                         1 |
+---------------------------+
1 row …

我们允许我们的用户dbo在他们自己的数据库中，但是这确实使他们能够删除他们自己的数据库。这并不经常发生，但我想阻止他们这样做。

我设计了以下触发器来防止这种情况发生，并将数据库删除到sysadmin角色成员：

CREATE TRIGGER [deny_customer_db_drop]
ON ALL SERVER
FOR DROP_database
AS
IF IS_SRVROLEMEMBER('sysadmin') = 0
BEGIN
    PRINT 'You are not permitted to drop this database'
    ROLLBACK
END
GO

这有效，但我想知道是否有更优雅的方法来使用权限而不调整每个登录自己的特定权限？

我有一种方法可以查询 SQL Server 2005+ 的各种日志文件的文件系统位置。我的意思是文本日志文件，而不是数据库事务日志文件？

例如，我的 SQL 代理、错误日志和维护计划都写入一个名为：

D:\MSSQLData\MSSQL.1\MSSQL\LOG

我需要找到这个文件夹的名称。

更新：

除了寻找 SQL 书籍之外，我还浏览了下的注册表

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer

和

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSSQLSERVER` 

但没有什么跳出来给我。

我也想要一种“官方”的方式来实现这一点，而不是依赖于未记录的功能。

我正在MySQL Server从我下载的源代码分发版进行安装：

http://dev.mysql.com/downloads/mysql/#downloads。

我已经下载了文件(mysql-5.5.19.tar.gz)。

我正在使用 Debian/Ubuntu 机器。我正在按照MySQL 文档中给出的说明进行操作。

在cmake .shell发出后，我收到以下错误：

-- MySQL 5.5.19
-- Could NOT find Curses  (missing:  CURSES_LIBRARY CURSES_INCLUDE_PATH)
CMake Error at cmake/readline.cmake:83 (MESSAGE):
  Curses library not found.  Please install appropriate package,

      remove CMakeCache.txt and rerun cmake.On Debian/Ubuntu, package name is libncurses5-dev, on Redhat and derivates it is ncurses-devel.
Call Stack (most recent call first):
  cmake/readline.cmake:127 (FIND_CURSES)
  cmake/readline.cmake:217 (MYSQL_USE_BUNDLED_LIBEDIT)
  CMakeLists.txt:257 (MYSQL_CHECK_READLINE)


-- Configuring incomplete, errors occurred!

为什么我收到这个错误？