解決python mysql insert語句的問題

1、python 數(shù)據(jù)插入問題

par=[]
for a in params:
if type(a) == list:
par.append(‘“str(a)”')
else:
par.append(a)
for b in par:
print()
cursor.execute(sql,tuple(par))

解決 注意python中的 extend，append 的區(qū)別，在數(shù)據(jù)添加數(shù)據(jù)庫中的時候,如果列表中列表一定將列表轉(zhuǎn)為 str 類型，

params 中的 append 添加記錄數(shù)據(jù)

2、轉(zhuǎn)為字符串可以插入

[{‘name': ‘0', ‘value': ‘1.0114'}, {‘name': ‘1-90天', ‘value': ‘0.0114'}, {‘name': ‘180天以上', ‘value': ‘0.0445'}, {‘name': ‘91-180天', ‘value': ‘0.0279'}]

3、 數(shù)據(jù)庫字段太小

alter table 表面 modify 字段名 字段類型 not null comment “ ” 注釋

4、修改表字段大小

如果要是報

not all params used in mysql statement 說明，占位符少了

not enough params used in mysql statement 說明，占位符多了

補充：python中的insert和append

兩者都是對python內(nèi)的列表進行操作，append()方法是值在列表的末尾增加一個數(shù)據(jù)項，insert()方法是指在某個特定位置前加一個數(shù)據(jù)項。

Python內(nèi)的list實現(xiàn)是通過數(shù)組實現(xiàn)的，而不是鏈表的形式，所以每當執(zhí)行insert()操作時，都要將插入位置的元素向后移動才能在相應(yīng)的位置插入元素，執(zhí)行append()操作時，如果分配的空間還足夠大的話那么就可以直接插到最后，如果空間不夠的話就需要將已有的數(shù)據(jù)復(fù)制到一片更大的空間后再插入新元素，insert()空間不夠的話也是同樣。

補充：Python中列表的append操作比insert操作效率高的實質(zhì)

Python中的列表并不是傳統(tǒng)意義上的列表，這也是Python中列表的append操作比insert操作高效的根本原因。

傳統(tǒng)意義上的列表，通常叫做鏈表，是通過一系列的節(jié)點來實現(xiàn)的，每個節(jié)點（尾節(jié)點除外）都有一個指向下一個節(jié)點的指針。

簡單單向鏈表（雙向鏈表多一個指向前一個節(jié)點的指針）實現(xiàn)如下：

class Node:
def __init__(self,value,next=Node)
self.value=value
self.next=next
將節(jié)點構(gòu)造成列表：
>>>L=Node("a",Node("b",Node("c",Node("d"))))
>>>L.next.next.value
'c'

但是Python中的列表則與此不同。

它不是由若干個獨立的節(jié)點相互引用而組成的，而是一整塊單一連續(xù)的內(nèi)存區(qū)塊--我們通常稱之為數(shù)組。這直接導致其與鏈表之間的一些區(qū)別。

例如，盡管兩者在遍歷時的效率相差無幾（除了鏈表有一些額外開銷），但是如果我們按照既定索引值對某元素進行直接訪問的話，顯然使用數(shù)組會更加的高效。

因為在數(shù)組中，我們通常可以直接計算出目標元素在內(nèi)存中的位置，并對其進行直接訪問。而對于鏈表，我們需要從頭開始遍歷整個鏈表。

但是對于insert操作來說，情況又有所不同。

對于鏈表而言，只要知道了在哪里執(zhí)行insert操作，其操作成本是非常低的。

無論該鏈表中有多少元素，其操作時間大致相同。但是，對于數(shù)組而言，每次執(zhí)行insert操作都需要移動插入點右邊所有的元素，甚至在必要時需要把所有數(shù)組元素復(fù)制到另外一個更大的數(shù)組中。

也正因如此，append操作通常會采用一種被稱為動態(tài)數(shù)組或向量的特定解決方案。

其主要思路是將內(nèi)存分配的過大一些，并且等到其溢出時，在線性時間內(nèi)再次重新分配內(nèi)存。但這樣做似乎會使得append操作變得跟insert操作一樣糟糕。

其實不然，因為盡管這兩種情況會迫使我們?nèi)グ釀哟罅康脑?，但主要的不同點在于，對于append操作，發(fā)生這樣的可能性要小得多。

事實上，只要我們能確保每次所搬入的數(shù)組都大過原數(shù)組一定的比例（例如20%甚至100%），那么該操作的平均成本（或者說的更確切一些，將這些搬運開銷均攤到每次append操作中去）通常是常數(shù)的。

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。如有錯誤或未考慮完全的地方，望不吝賜教。