A. sql一張表插入到另一張表（主鍵不會處理）
主鍵有問題？情況如下：
1.主鍵列有重復數據。先檢查資料庫是否重復。
2.主鍵是自增ID，不需要插入了。insert的時候這個值。
3.長度或者欄位類型不同，修改一下主鍵的長度和欄位類型吧。
B. 怎麼用sql語句建立GUID類型的自動編號的主鍵
怎麼用sql語句建立GUID類型的自動編號的主鍵
mysql oracle 都沒有自動增長列，資料庫里沒辦法設。Guid我是用C#生成的。
C. c#中Guid的作用是什麼
借鑒了網上的一些看法：
1. 一個GUID為一個128位的整數(16位元組)，在使用唯一標識符的情況下，你可以在所有計算機和網路之間使用這一整數。
2. GUID 的格式為「xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx」，其中每個 x 是 0-9 或 a-f 范圍內的一個十六進制的數字。例如：337c7f2b-7a34-4f50-9141-bab9e6478cc8 即為有效的 GUID 值。
3. 世界上（Koffer註：應該是地球上）的任何兩台計算機都不會生成重復的 GUID 值。GUID 主要用於在擁有多個節點、多台計算機的網路或系統中，分配必須具有唯一性的標識符。
4. 在 Windows 平台上，GUID 應用非常廣泛：注冊表、類及介面標識、資料庫、甚至自動生成的機器名、目錄名等。
以下的C#命令行程序說明這一使用過程：
using System;
namespace DisplayGUID {
class GuidExample {
static void Main(string[] args) {
GenerateGUID();
}
static void GenerateGUID() {
Console.WriteLine("GUID: " + System.Guid.NewGuid().ToString());
} } }
下面為這一程序的輸出：(雖然不同系統之間的GUID是變化的。)
GUID: 9245fe4a-d402-451c-b9ed-9c1a04247482
一個GUID可以在後台資料庫中操作一個主鍵。以下代碼使用一個GUID在一個後台資料庫中存儲信息，這一資料庫包含以下的列：
pk_guid—uniqueidentifier數據類型
name—nvarchar數據類型
這樣出現一個包含文本框的簡單Windows窗體。當選擇按鈕時，文本框中的數據被插入到資料庫中。通過程序代碼可以生成一個GUID並存儲在其它列中：
using System;
using System.Drawing;
using System.Collections;
using System.ComponentModel;
using System.Windows.Forms;
using System.Data;
using Microsoft.ApplicationBlocks.Data;
namespace GuidDBExampleCSharp {
public class frmBuilderTest : Form {
private Label lblName;
private TextBox txtName;
private Button btnInsert;
private Container components = null;
public frmBuilderTest() {
InitializeComponent();
}
static void Main() {
Application.Run(new frmBuilderTest());
}
private string GenerateGUID() {
return System.Guid.NewGuid().ToString();
}
private void btnInsert_Click(object sender, System.EventArgs e) {
string cs = "server=(local);Initial Catalog=Northwind;Integrated
Security=SSPI";
using ( SqlConnection conn = new SqlConnection(cs) ) {
try {
string sqlInsert = "INSERT INTO dbo.tblBuilderTest (pk_guid, [name]) VALUES ('"
+ System.Guid.NewGuid().ToString() + "', '" + txtName.Text + "')";
conn.Open();
SqlHelper.ExecuteNonQuery(conn, CommandType.Text, sqlInsert);
} catch(Exception ex) {
System.Console.Write("Error: " + ex.Message);
} } } } }
另一個GUID程序將一個唯一的標識符分配給一個.NET類或者介面，也就是說，GUID作為一個屬性被分配給類或者介面。可以使用標准屬性語法來實現這一過程：
我們可以擴展第一個範例來分配一個GUID。System.Runtime.InteropServices空間名稱必須被引用來使用GUID屬性。以下C#代碼實現了這一過程：
using System;
using System.Runtime.InteropServices;
namespace DisplayGUID {
[Guid("9245fe4a-d402-451c-b9ed-9c1a04247482")]
class GuidExample {
static void Main(string[] args) {
GenerateGUID();
}
static void GenerateGUID() {
Console.WriteLine("GUID: " + System.Guid.NewGuid().ToString());
} } }
D. mysql資料庫表用什麼做主鍵
1、主鍵定義
表中經常有一個列或多列的組合，其值能唯一地標識表中的每一行。這樣的一列或多列稱為表的主鍵，通過它可強製表的實體完整性。當創建或更改表時可通過定義 PRIMARY KEY 約束來創建主鍵。一個表只能有一個 PRIMARY KEY 約束，而且 PRIMARY KEY 約束中的列不能接受空值。由於 PRIMARY KEY 約束確保唯一數據，所以經常用來定義標識列。
2、主鍵作用
1）保證實體的完整性;
2）加快資料庫的操作速度
3） 在表中添加新記錄時，資料庫會自動檢查新記錄的主鍵值，不允許該值與其他記錄的主鍵值重復。
4） 資料庫自動按主鍵值的順序顯示表中的記錄。如果沒有定義主鍵，則按輸入記錄的順序顯示表中的記錄。
3、主鍵的必要性
在有些資料庫中，雖然主鍵不是必需的，但最好為每個表都設置一個主鍵，不管是單主鍵還是復合主鍵。它存在代表著表結構的完整性，表的記錄必須得有唯一區分的欄位，主鍵主要是用於其他表的外鍵關聯，以及本記錄的修改與刪除。
4、主鍵的選擇
1）編號作主鍵
此方法就是採用實際業務中的唯一欄位的「編號」作為主鍵設計，這在小型的項目中是推薦這樣做的，因為這可以使項目比較簡單化，但在使用中卻可能帶來一些麻煩，比如要進行「編號修改」時，可能要涉及到很多相關聯的其他表
2）自動編號主鍵
這種方法也是很多人在使用的，就是新建一個ID欄位，自動增長，非常方便也滿足主鍵的原則
a、優點：資料庫自動編號，速度快，而且是增量增長，聚集型主鍵按順序存放，對於檢索非常有利;數字型的，佔用空間小，易排序，在程序中傳遞也方便;如果通過非系統增加記錄（比如手動錄入，或是用其他工具直接在表裡插入新記錄，或老系統數據導入）時，非常方便，不用擔心主鍵重復問題。
b、缺點：其實缺點也就是來自其優點，就是因為自動增長，在手動要插入指定ID的記錄時會顯得麻煩，尤其是當系統與其他系統集成時，需要數據導入時，很難保證原系統的ID不發生主鍵沖突（前提是老系統也是數字型的）;如果其他系統主鍵不是數字型那就麻煩更大了，會導致修改主鍵數據類型了，這也會導致其他相關表的修改，後果同樣很嚴重;就算其他系統也是數字型的，在導入時，為了區分新老數據，可能想在老數據主鍵前統一加一個「o」(old)來表示這是老數據，那麼自動增長的數字型又面臨一個挑戰。
3）Max加一
由於自動編號存在那些問題，所以有些人就採用自己生成，同樣是數字型的，只是把自動增長去掉了，採用在Insert時，讀取Max值後加一，這種方法可以避免自動編號的問題，但也存在一個效率問題，如果記錄非常大的話，那麼Max()也會影響效率的;更嚴重的是並發性問題，如果同時有兩人讀到相同的Max後，加一後插入的ID值會重復，這已經是有經驗教訓的了。
4）自製加一
考慮Max加一的效率後，有人採用自製加一，也就是建一個特別的表，欄位為：表名，當前序列值。這樣在往表中插入值時，先從此表中找到相應表的最大值後加一，進行插入，有人可能發現，也可能會存在並發處理，這個並發處理，可以採用lock線程的方式來避免，在生成此值的時，先Lock，取到值以後，再unLock出來，這樣不會有兩人同時生成了。這比Max加一的速度要快多了。但同樣存在一個問題：在與其他系統集成時，脫離了系統中的生成方法後，很麻煩保證自製表中的最大值與導入後的保持一致，而且數字型都存在上面講到的「o」老數據的導入問題。因此在「自製加一」中可以把主鍵設為字元型的。字元型的自製加一中應該字元型主鍵可以應付很多我們意想不到的情況。
5）GUID主鍵
目前一個比較好的主鍵是採用GUID，推薦主鍵還是字元型的，但值由GUID生成，GUID是可以自動生成，也可以程序生成，而且鍵值不可能重復，可以解決系統集成問題，幾個系統的GUID值導到一起時，也不會發生重復，就算有「o」老數據也可以區分，而且效率很高，在.NET里可以直接使用System.Guid.NewGuid()進行生成，在SQL里也可以使用NewID()生成。優點是：
同IDENTITY 列相比，uniqueidentifier 列可以通過NewID() 函數提前得知新增加的行ID，為應用程序的後續處理提供了很大方便。
a、優點：便於資料庫移植，其它資料庫中並不一定具有IDENTITY 列，而Guid 列可以作為字元型列轉換到其它資料庫中，同時將應用程序中產生的GUID 值存入資料庫，它不會對原有數據帶來影響。便於資料庫初始化，如果應用程序要載入一些初始數據，IDENTITY 列的處理方式就比較麻煩，而uniqueidentifier 列則無需任何處理，直接用T-SQL 載入即可。便於對某些對象或常量進行永久標識，如類的ClassID，對象的實例標識，UDDI 中的聯系人、服務介面、tModel標識定義等。
b：缺點是：
GUID 值較長，不容易記憶和輸入，而且這個值是隨機、無順序的
GUID 的值有16 個位元組，與其它那些諸如4 位元組的整數相比要相對大一些。這意味著如果在資料庫中使用uniqueidentifier 鍵，可能會帶來兩方面的消極影響：存儲空間增大；索引時間較慢。
E. 我創建mysql數據表的時候沒有考慮清楚，主鍵設置錯了，現在現更改。報了這個錯，大神們幫我看下，謝謝啦
最常見的主鍵數據類型是數字類型、固定長度的字元類型和GUID類型。通常情況下，RDBMS會在主鍵上建立聚集索引（SQL Server默認都這么做），由於我們使用B-Tree的數據結構來存儲索引數據，所以一般對主鍵有以下兩個要求：
越短越好——越短在一個Page中存儲的節點越多，檢索速度就越快。
順序增長——如果每一條插入的數據的主鍵都比前面的主鍵大，那麼B-Tree上的節點也是順序增長的，不會造成頻繁的B-Tree分割。
越短越好是為了查詢的速度快，順序增長是為了插入速度快。
有了這兩個要求，我們再來分析下各個數據類型：
數字類型：根據數據量決定是用Int16還是Int32或者Int64，能用Int32的就不需要使用Int64。
字元類型：基本不滿足前面提到的2點要求，字元類型一般不會很短，而且也很可能不是順序增長的，所以不是特別推薦的主鍵類型。當然如果確實業務需求使用字元類型，那麼也盡量使用char(XX)而不要使用varchar(XX)，因為在RDBMS中，對於定長字元串和變成字元串的數據結構和處理是不一樣的，varchar的性能更差。
GUID類型：這個類型並不是所有資料庫都有對應的數據類型，SQL Server有uniqueidentifier，MySQL沒有。GUID類型在SQL Server中是16個位元組，不算短，比4個位元組的Int32長多了。在插入新數據時，GUID一般都是使用NewId()這樣的生成隨機GUID的方式生成的，所以也不是順序增長的，在插入速度上不會很快。
通過上面的比較，我們知道使用數字類型是更好的方式，那麼我們為什麼還會有人使用GUID和字元串來當主鍵呢？那是因為：
相對於數字類型，字元類型更易讀易記，在檢索關聯的數據時，更方便直接。
GUID的優勢是全球唯一，也就是說同樣的系統，如果部署了多套環境，那麼裡面的數據的主鍵仍然是唯一的，這樣有助於數據的集成。典型的例子就是一個系統在全國每個省份都部署一套，每個省份的數據各種錄入，互不幹擾，然後再把每個省的數據集成起來為總部做分析。
F. sql server2012怎麼在每個表創建主鍵並不重復
不重復的主鍵列可以選擇自增列或者使用32位的guid字元串自增列
對於這兩種方式，都需要對已有數據進行主鍵填充
DECLARE @i int
SET @i=0
UPDATE table1 SET @i=@i+1,ID=@i
這段代碼是對自增列已有數據填充
G. c#向sql中插入數據時如何自動生成編號作為主鍵
創建表格的時候將主鍵設定為IDENTITY
CREATETABLETest
(
IdINTPRIMARYKEYIDENTITY,
ValueNVARCHAR(128)NOTNULL
)
插入數據的時候，不要給主鍵賦值，主鍵會自動增長
INSERTINTOTestVALUES('Value1')
INSERTINTOTestVALUES('Value2')數據表中的數據為：
IdValue
1Value1
2Value2
當然，如果你不希望Id從1開始，或者希望每條記錄之間的增量不為1，你可以這樣來創建你的表格：
CREATETABLETest
(
IdINTPRIMARYKEYIDENTITY(10000,2),
ValueNVARCHAR(128)NOTNULL
)
這樣，你的表格中的第一條記錄的Id就是10000，而每次增加一條記錄，Id的增量為2.
H. SQL 中Guid 怎麼優化
1、生成我覺得可以先預生成一定數量的GUID備用，然後使用時候，從這個表取。如果表的使用量低於50%，則自動填滿。
2、GUID是由網卡地址和CPU時間戳生成的，很可能前面都是重復的部分，完全可以忽略重復的，比較不重復的做索引排序依據。
I. sql server 將一個整數轉為7個長度的字元串
這個應該沒有難度，但是有一點不明白，沒明白你具體想問什麼，當超過7位用字元替換，但是是什麼規則呢？或者你就是想問怎麼設定規則？
如果你就是想問規則的話，我想需要按照你那個表實際需要存儲多少數據來看，如果存儲的數據是海量，主鍵設定成7位的字元串，本身就是錯誤的。
給你幾點建議吧
1、如果不幸被言重，你的表是海量數據，無邊無際，主鍵用guid吧（sql server中NEWID()自動產生guid），或者用bigint（沒有真的無邊無際的數據吧，真的無邊無際就用GUID吧），我們大數據都用bigint做主鍵，你可以考慮一下。
2.如果數據量不是很大，只要找到合適的規則，7位字元串一定夠用（也不建議7位字元串，就是一個主鍵，弄個邏輯主鍵就行了，為什麼要7位字元串呢？好吧，假設你們也無特殊，必須7位字元串），你可以考慮用16進制的數字，不夠7位的前面補0，這樣你主鍵的容量一下子由10的7次冪變成16的7次冪，還不夠，換成32進制，這樣就變成32的7次冪了，這樣應該夠了吧。
好了，就寫這么些了，就是個建議，權當給你擴展一下思路，不過，7位字元串的主鍵，主鍵還用觸發器來維護（觸發器不穩定的，至少我這么看），好蛋疼啊，哈哈。
J. sql 獲取當前插入的主鍵 表主鍵是guid類型的
@@IDENTITY只能獲取表中identity類型的值，guid的好像只能寫方法或者觸發器自己獲得了
另外guid雖可唯一標示，但是並不順序增長，所以拿來做主鍵可以，但是做聚集索引就沒什麼意義了，最後自己再加一列identity型的唯一列來標示