看完必恍然大悟的活字格内幕：二十四，性能问题教程一（主键）

很多实用活字格真正做出了应用的朋友，有的时候会发现有的页面这么打开的时候，这么慢啊！！！
甚至会怀疑活字格产品的能力，怀疑产品的性能。
我非常理解大家的心情，但是做过开发的我，再次给大家说一下，其实即使你使用代码开发，如果你的代码书写不当的话，肯定也会遇到很多的性能问题，但是那不是因为这个代码本身不好。
其实，无论是活字格还是代码，他们本质都是一种工具，你使用的方法不当的话，都会出现性能问题。

我会和我同事一起，将我们的日常碰见大家容易犯，且有可能导致性能的问题，在此跟大家分享，希望后面的老铁，不要再犯同样的问题。
PS：如果大家在使用活字格的时候，遇到了任何性能问题的话，非常欢迎大家直接找我，性能问题我们一定优先解决。

今天要跟大家将的第一个性能问题，也是最简单的一个会导致性能的问题，就是主键。
（如果您是一个对数据库还比较了解的朋友，这个概念就不单单是主键，而是索引，主键是索引的一种；如果您不太了解数据库的话，请跳过这个括号中的话，因为其实主键基本够用了，能解决80%的问题。）

首先，如果您使用的是活字格内置的数据的话，那这个问题，您不用担心，因为活字格内置的数据库自带主键，就是我们画了一个小钥匙的这一列

当然，如果您使用外部数据库的话，主键您一定要注意啦~~

这个主键，到底是有多影响性能呢？
我来跟大家分享一个例子吧，
有一个使用活字格的兄弟，他们出租车公司有一个老系统是使用的sqlserver数据的（印象中：这个数据库是保存司机位置的数据库），目前也就有个800多万行数据吧，他想把这个表中的一些数据，展示在活字格的的网页中，使用分页这样想着不把所有的数据的都加载起来，应该就会很快。
事实上，当时我也是这么觉得，因为不怕大家觉得我吹牛，当时我们一个客户（运输公司，名称人家不让我说），他们当时有一个3500万行的数据库，在活字格使用动态加载，每页显示200条数据都是秒开的，分页以后也是只加载一页的数据。

结果，这位朋友使用活字格做出来的网页，打开一下2分钟，当时我就觉得太不可思议了，难道它使用的是一个假的活字格？

然后我就远程过去，发现他确实在使用活字格连接，也确实使用了分页，那怎么还是这么慢呢？
于是我们一起远程到他的数据库中，然后，我尝试看看这个数据到底有多少条，于是一条数据库SQL语句在他数据库中执行
SELECT COUNT(column_name) FROM table_name
结果，直接在数据库执行一次这个语句（没有使用活字格，直接在数据库中执行，也就和活字格没有任何关系的情况下），我整整等了快2分钟，结果数据库中也就大概是个800万+条数据，于是我合理的猜想是这个数据库本身慢；
但是为什么这么慢呢？  对于一个数据库来说，这个性根本不可能啊？
于是我们的开始调查，调查的结果就是这个表没有主键；
于是我们开始给这个表设置主键,向下面一条设置主键的语句

1. ALTER TABLE Persons
   
2. ADD PRIMARY KEY (ID);

复制代码

数据库执行了10分钟


设置完主键，我又重新测试了一下，查询表中行数的SQL，结果秒开；
重新在活字格中，重新连接，这个表，绑定到页面上，打开这个页面只需要1s.

主键对性能的关键性，不言而喻，大家以后如果在使用外部数据库的时候，一定要记住，设置主键；
遇到连接进来没有小钥匙的情况一定要注意

将他改成