MYSQL教程之翻开UDP端口1434以扫瞄定名实例
当然，或许这并不是我们拒绝MySQL的一个有说服力的MySQL学习教程，但是对于一些比较守旧的IT经理来说，在为一些关键业务选择平台的时候，平台的成熟性却是必须要考虑的一个因素，在这一点上，MySQL无疑毫无优势。问：当地的一个ISP托管了我们的SQLServer，可是我不克不及看到或毗连到运转在该盘算机上的定名实例。我晓得SQLServer2000定名实例不利用TCP/IP1433端口，而且断定该SQLServer实例所利用的TCP/IP端口是翻开的。您有甚么倡议吗？<P>答：很多人晓得怎样利用SQLServer收集有用工具或SQLServer毛病日记来断定SQLServer实例的监听端口。但很多人仿佛健忘大概基本不晓得――UDP1434端口也必需是翻开的，以确保您可以准确地会见和扫瞄定名实例。我倡议您细心研讨一下这一请求。在SQLServer在线书本中搜刮“1434”，您将失掉三个很有研讨代价的搜刮了局。在SQLServer杂志网站2001年7月刊我的SQLServer有用技能专栏中，您还能够查找到有关会见定名实例的信息（InstantDocID21127）。在此我也复杂注释一下。SQLServer在UDP1434端口上创建一个监听服务，让客户端从服务器上查询到定名实例及其收集设置信息的一个列表。该监听服务一直运转在UDP1434端口上，而且用户没法变动该运转端口。 语句级快照和事务级快照终于为SQLServer的并发性能带来了突破。个人感觉语句级快照大家应该应用。事务级快照，如果是高并发系统还要慎用。如果一个用户总是被提示修改不成功要求重试时，会杀人的！ 微软对CLR作了大篇幅的宣传，这是因为数据库产品终于融入.net体系中。最开始我们也是狂喜，感觉对象数据库的一些概念可以实现了。 可能有的朋友会抱怨集成的orderby，其实如果使用ranking函数,Orderby是少不了的。如果担心Orderby会影响效率，可以为orderby的字段建立聚集索引，查询计划会忽略orderby操作（因为本来就是排序的嘛）。 对于微软系列的东西除了一遍遍尝试还真没有太好的办法 原来公司用过MYSQL自己也只是建个表写个SQL 你觉得我的非分区索引无法对起子分区，你可以提醒我一下呀！没有任何的提醒，直接就变成了非分区表。不知道这算不算一个bug。大家也可以试试。 每天坚持做不一样的是，认真做笔录，定时复习。一个月你就可以有一定的收获。当然如果你想在sql方面有一定的造诣，你少不了需要看很多很多的书籍了。
页:
[1]