這個問題可以分成三個層次來回答：

從理論方面，在資料庫的教材中題到，primary key 是該 table 中具有唯一性與識別性的資料，若沒有單一資料具有此特性，也可以是兩個以上的資料合成具有此特性的 key 值，即可做為 primary key。是故，比如身份證號可以是個人資料的 PK，比如時間日期與發生標的物兩個欄位可以合成 Log 的 PK。

從實作方面，牽涉到開發工具、效能、使用的 DB 是否支援以及其最佳化的依據，通常會是以數值欄位、避免複合欄位等等為實作考量，因此很常見的是每個 table 都會開一個 auto increment 的欄位來做為 PK，不過這也違反資料庫理論中的《不在一個 table 中使用兩個具有重覆屬性的欄位》這個原則。比如個人資料 table 中，身份證號已經可以當 PK，但你又加一個 auto increment 的欄位來做為 PK，這就是浪費。

而從我的觀點，怎麼選 PK 只有一個原則：我的經驗。

PK 完再決定....(大誤)

個人會考慮:

1. 將來可能筆數? ( 2 年, 5 年, 10 年, 終生?)
2. 查詢方便性? (是否需要人工查詢或核對?)
3. 除了系統外, 是否有使用於其他地方? (例如當成單據號?)

大約這樣去考慮.

要替Table加上PK,原則很簡單,就是您最常用那個欄位(或那幾個欄位,大部份情形是兩個,最好不要超過3個)作條件來查詢這個Table內的某一筆特定資料。

例如：員工資料表就是用員工編號(或身份證字號)，訂單主檔就是訂單編號，訂單明細檔就是用訂單編號+項次。

因為大部份資料庫都會以PK作為資料存取優化的條件,例如在SQL Server中會依PK值作排序來存放每一筆記錄的順序，讓您在用PK作查詢條件時，能以最快的速度將資料取出。

學過的經驗告訴我 . 身份證字號理論上是 唯一性 但是 實務上不是唯一
故以系統的 PK 當作唯一是比較保險的做法
很多事情難保不會有例外

前面幾位已經說明很多,敝人在此不贅述.
樓主似乎是對UUID 與一般自動增加的方式,想做個了解.
在此作個測試.
產生測試資料,先參考敝人之前鐵人賽裡的測試資料的產生.
http://ithelp.ithome.com.tw/question/10133871

<pre class="c" name="code">SET SESSION max_heap_table_size = 1024 * 1024 * 200; 

CALL prc_filler(1000000);
Query OK, 1 row affected (11.30 sec)

select count(1) from filler;
+----------+
| count(1) |
+----------+
|  1000000 |
+----------+

這樣就建立了一個一百萬筆的Table.
接著來建立幾個測試Table

CREATE TABLE ithelp1220a(
id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
pad CHAR(200),
instime TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE ithelp1220b(
id INT UNSIGNED NOT NULL PRIMARY KEY,
pad CHAR(200),
instime TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE ithelp1220c(
id CHAR(36) NOT NULL PRIMARY KEY,
pad CHAR(200),
instime TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE ithelp1220d(
id BINARY(16) NOT NULL PRIMARY KEY,
pad CHAR(200),
instime TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

利用filler來產生測試資料.

INSERT INTO ithelp1220a(pad)
SELECT REPEAT('a', 200)
  FROM filler;

Query OK, 1000000 rows affected (37.02 sec)
Records: 1000000  Duplicates: 0  Warnings: 0

INSERT INTO ithelp1220b(id, pad)
SELECT id, REPEAT('a', 200)
  FROM filler;

Query OK, 1000000 rows affected (31.47 sec)
Records: 1000000  Duplicates: 0  Warnings: 0

INSERT INTO ithelp1220c(id, pad)
SELECT UUID(), REPEAT('a', 200)
  FROM filler;

Query OK, 1000000 rows affected (42.51 sec)
Records: 1000000  Duplicates: 0  Warnings: 0

INSERT INTO ithelp1220d(id, pad)
SELECT UNHEX(REPLACE(UUID(),'-','')), REPEAT('a', 200)
  FROM filler;

Query OK, 1000000 rows affected (35.02 sec)
Records: 1000000  Duplicates: 0  Warnings: 0

觀察空間大小

SELECT table_name  
     , data_length / 1024 AS 'data(K)'
     , row_format
  FROM INFORMATION_SCHEMA.TABLES  
 WHERE table_name LIKE 'ithelp1220%'
 ORDER BY table_name;

+-------------+-------------+------------+
| table_name  | data(K)     | row_format |
+-------------+-------------+------------+
| ithelp1220a | 243456.0000 | Compact    |
| ithelp1220b | 243456.0000 | Compact    |
| ithelp1220c | 277504.0000 | Compact    |
| ithelp1220d | 233376.0000 | Compact    |
+-------------+-------------+------------+

接著來觀察 1000萬筆資料的情形.
依樣葫蘆,建立3個空的Table,比較自動增加與兩種UUID的.

CREATE TABLE ithelp1220a1 LIKE ithelp1220a;

CREATE TABLE ithelp1220c1 LIKE ithelp1220c;

CREATE TABLE ithelp1220d1 LIKE ithelp1220d;

INSERT INTO ithelp1220a1(pad)
SELECT REPEAT('a', 200)
  FROM ( SELECT id
           FROM filler) a,
       ( SELECT id
           FROM filler
          LIMIT 10) b;

Query OK, 10000000 rows affected (6 min 9.34 sec)
Records: 10000000  Duplicates: 0  Warnings: 0

INSERT INTO ithelp1220c1(id, pad)
SELECT UUID(), REPEAT('a', 200)
  FROM ( SELECT id
           FROM filler) a,
       ( SELECT id
           FROM filler
          LIMIT 10) b;

Query OK, 10000000 rows affected (10 min 19.08 sec)
Records: 10000000  Duplicates: 0  Warnings: 0

INSERT INTO ithelp1220d1(id, pad)
SELECT UNHEX(REPLACE(UUID(),'-','')), REPEAT('a', 200)
  FROM ( SELECT id
           FROM filler) a,
       ( SELECT id
           FROM filler
          LIMIT 10) b;

Query OK, 10000000 rows affected (10 min 39.95 sec)
Records: 10000000  Duplicates: 0  Warnings: 0


觀察空間大小
SELECT table_name  
     , data_length / 1024 AS 'data(K)'
     , row_format
  FROM INFORMATION_SCHEMA.TABLES  
 WHERE table_name IN ('ithelp1220a1', 'ithelp1220c1', 'ithelp1220d1')
 ORDER BY table_name;

+--------------+--------------+------------+
| table_name   | data(K)      | row_format |
+--------------+--------------+------------+
| ithelp1220a1 | 2311168.0000 | Compact    |
| ithelp1220c1 | 3109888.0000 | Compact    |
| ithelp1220d1 | 2820096.0000 | Compact    |
+--------------+--------------+------------+

使用UUID方式,消耗時間較久,
空間會佔用較多,這是資料庫系統內部實作的關係.
若有想要進一步了解,篇幅較長,改日再探討吧.

1.系統OO化.別人都用正規化.正規化我不會,我習慣用物件導向方式
2.小系統用Int,流水號,不要用字串,int 是電腦處理基礎單位,所以排序,索引..最快
3.分散式DB用GUID 全世界每一個資料拋過來都不會沖到,而且是Client 端,App端產生
4.PK給App 給 DB 關聯看,所以只要不重複,容易電腦計算,如果給Users識別用,我會再用一組有規律的Key讓Users記