不同的企业，对于数据库可能会提出不同的个性化需求。如日期显示的格式等等。为了满足不同企业在这方面的要求，在MySQL数据库中提出了服务器变量的概念。通过对这些变量进行调整，数据库管理员可以建立起一个符合企业实际情况的应用环境。在这里，笔者就结合自己的工作经验，谈谈如何对服务器变量进行调整，以及相关的注意事项。
一、查看系统现有变量的值
数据库管理员如果需要对服务器变量进行调整，首先需要对现有的变量以及相关值有所了解。用户可以通过使用命令show variables来查看系统中可用的变量以及默认值。不过系统的变量有200多个，查找起来比较麻烦。为此，用户可以通过使用like查询条件加上通配符来进行快速查找。如下图所示，笔者使用了’date%’，系统就会列出所有以date开头的变量名。这与SQL语句中的查询条件非常的类似。
使用通配符与Like关键字可以帮助数据库管理员迅速定位相关的变量。不过在使用通配符时，需要注意，两边的单引号不能够忘记。否则的话，系统就会报错。其次，在这个命令行环境下，对于大小写是不敏感的。也就是说，’date%’与’Date%’两个是等价的。这对于一些大小写不分的数据库管理员来说，是一个不错的特性。不过在输入条件语句时，有一个细节需要注意，即空格。在查询时，系统不会自己过滤空格。’date%’与’ date%’两个语句有什么区别吗 粗粗的一看，好像是相同的。其实两个是不同的内容。后面一个在date前面有一个空格，而第一个没有。此时从数据库中得到的结果也是截然相反。由于系统变量前面都没有空格，所以采用后面一个语句，将查不到任何可用的变量。为此在查询时，需要注意空格对查询语句的影响。
二、区分全局变量与会话变量
在开发环境中，变量一般会有全局变量与局部变量的区分。两者核心的差异就是作用域不同。对于MySQL数据库来说，也有这方面的定义。MySQL数据库的变量可以分为全局变量与会话变量。两者的主要区别也在于作用域的不同。
全局变量，顾名思义，会影响到服务器的全局操作。在数据库服务器启动的过程中，系统会将所有全局变量初始化为默认值。当然，数据库管理员可以根据需要，在选型文件或者命令行中指定相关的选项来更改这些默认值。即使在服务器启动之后，数据库管理员仍然可以通过执行Set Global 变量名的方式来更改动态全局变量。
会话变量只是针对某个特定的会话有效，而不会对其他会话产生影响。服务器还会为每个客户端连接维护会话变量。在连接时，如果没有为某个特定的会话设置值的话，系统会用全局变量来初始化会话变量。同样，用户也可以通过Set Session 变量名来更改动态会话变量。
在对全局变量或者会话变量进行更改时，需要注意权限问题。如果对全局变量进行更改，则需要注意，用户必须要有Super权限。但是如果对会话变量进行更改的话，则默认情况下不需要特殊权限。也就是说，用户可以更改自己会话的变量，但是不能够更改其他客户的会话变量。不过通常情况下，并不建议用户更改相关的会话变量。
三、更改后的生效时间
全局变量或者局部变量更改后，什么时候生效呢 这又是数据库管理员需要关注的内容。在讲解这个知识点时，笔者还是需要强调一下，各位要关注全局变量与会话变量的差异。只有掌握这个差异之后，对于变量更改的生效时间才会有更加深刻的认识。
对于全局变量来说，通常情况下，任何访问全局变量的客户端都可以看见对全局变量的更改。当全局变量进行更改时，它只影响在更改后连接的从该全局变量初始化相应会话变量的客户端，而不会影响已经连接上的客户端的会话变量，即使是执行了Set语句来更改也是如此。这主要说明了两点。一是全局变量的更改，并不像其他系统一样，需要重启系统后才会生效。不重新启动数据库系统也会生效。二是对于当前已经连接的客户不会生效，而只会对更改后的新会话有效。为此如果要测试某个全局变量的更改是否生效，数据库管理员不需要重新启动服务器，只需要新建一个会话就可以进行测试。测试完成后，如果确定需要使用这个更改，也不需要重新启动服务器。只需要先关闭当前的所有会话，让用户重新建立会话即可。
与此类似，会话变量更改之后，也不需要重新启动服务器即可生效。不过会话变量又与全局变量不同，其只对自己的会话有效。这也就是说，会话变量更改之后，在当前会话中就会有效。
如果数据库管理员要同步全部的应用环境，如整个信息化应用采用相同的时间格式，在这种情况下，笔者建议采用全局变量，而不是会话变量。比较会话变量的作用域比较有限。
四、更改后的测试与备份
无论是全局变量还是会话变量，更改后都会有一个测试的过程。对于全局变量更改的测试，笔者建议先采用小范围内的测试。如更改了日期显示格式之后，为了测试其有效性，笔者建议数据库管理员先建立一个新的会话，然后查看更改是否生效。而不要先急着重置所有的会话。如此的话，万一更改失败或者不理想，因为不会影响到已连接的会话(只会对更改后的新会话起效)，就可以将不利影响控制在最小的范围之内。不过这么做还需要控制整个时间。如这个时间间隔拖了很长，如一天24个小时，此时就会出现问题。如财务部门是在更改之前就连结了，而采购部门有一个用户是在更改之后再连接的。此时两个不同的用户导出来的表格上，时间显示的格式就可能不同。这会造成一定的误导。可见，这个策略有利也有弊。数据库管理员，应该将这个测试的时间尽量缩短。如果测试的时间比较长的话，那么最好再搭建一台服务器进行测试，而不要在生产服务器上直接进行测试。
另外，对于更改后的配置，最好进行独立的备份。这里的备份并不是对数据库的整体备份，而是说对配置文件的备份。而且还需要做好详细的说明。如为什么要进行这个调整、调整的时间点是什么。
为了保持应用前后的一致性，这个调整的时间其实也有讲究的。一般情况下，不要在一个工作日的中间进行调整。如中午12点进行调整等等。如此的话，就会导致上午与下午的单据出现混乱。在某些特殊的应用中，可能对这个调整的时间会有更加严格的要求。如对于财务软件的后台数据库，则相关全局变量的调整，可能需要考虑到会计期间的问题。其只能够在月末或者年末进行调整。所以对某个全局变量进行调整时，因为会对全部用户产生影响，为此在更改之前，需要征求所有用户的意见。然后根据企业的实际情况与用户的要求，选择一个合适的调整时间。通常情况下，一个比较有经验的数据库管理员，会了解更改哪些全局变量会对最终用户产生影响，而哪些全局变量只是对系统维护有影响。然后就会根据需要更改变量的影响范围，去判断是否需要经过最终用户的确认。如果能够做出这样的判断，那是最好。可将将对用户的影响降低到最低程度。