1、python 數(shù)據(jù)插入問(wèn)題
|
1
2
3
4
5
6
7
8
9
|
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ù)庫(kù)中的時(shí)候,如果列表中列表一定將列表轉(zhuǎn)為 str 類型，
params 中的 append 添加記錄數(shù)據(jù)
2、轉(zhuǎn)為字符串可以插入
|
1
|
[{‘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ù)庫(kù)字段太小
|
1
|
alter table 表面 modify 字段名 字段類型 not null comment “ ” 注釋 |
4、修改表字段大小
如果要是報(bào)
not all params used in mysql statement 說(shuō)明，占位符少了
not enough params used in mysql statement 說(shuō)明，占位符多了
補(bǔ)充：python中的insert和append
兩者都是對(duì)python內(nèi)的列表進(jìn)行操作，append()方法是值在列表的末尾增加一個(gè)數(shù)據(jù)項(xiàng)，insert()方法是指在某個(gè)特定位置前加一個(gè)數(shù)據(jù)項(xiàng)。
Python內(nèi)的list實(shí)現(xiàn)是通過(guò)數(shù)組實(shí)現(xiàn)的，而不是鏈表的形式，所以每當(dāng)執(zhí)行insert()操作時(shí)，都要將插入位置的元素向后移動(dòng)才能在相應(yīng)的位置插入元素，執(zhí)行append()操作時(shí)，如果分配的空間還足夠大的話那么就可以直接插到最后，如果空間不夠的話就需要將已有的數(shù)據(jù)復(fù)制到一片更大的空間后再插入新元素，insert()空間不夠的話也是同樣。
補(bǔ)充：Python中列表的append操作比insert操作效率高的實(shí)質(zhì)
Python中的列表并不是傳統(tǒng)意義上的列表，這也是Python中列表的append操作比insert操作高效的根本原因。
傳統(tǒng)意義上的列表，通常叫做鏈表，是通過(guò)一系列的節(jié)點(diǎn)來(lái)實(shí)現(xiàn)的，每個(gè)節(jié)點(diǎn)（尾節(jié)點(diǎn)除外）都有一個(gè)指向下一個(gè)節(jié)點(diǎn)的指針。
簡(jiǎn)單單向鏈表（雙向鏈表多一個(gè)指向前一個(gè)節(jié)點(diǎn)的指針）實(shí)現(xiàn)如下：
|
1
2
3
4
5
6
7
8
|
class Node:def __init__(self,value,next=Node)self.value=valueself.next=next將節(jié)點(diǎn)構(gòu)造成列表：>>>L=Node("a",Node("b",Node("c",Node("d"))))>>>L.next.next.value'c' |
但是Python中的列表則與此不同。
它不是由若干個(gè)獨(dú)立的節(jié)點(diǎn)相互引用而組成的，而是一整塊單一連續(xù)的內(nèi)存區(qū)塊--我們通常稱之為數(shù)組。這直接導(dǎo)致其與鏈表之間的一些區(qū)別。
例如，盡管兩者在遍歷時(shí)的效率相差無(wú)幾（除了鏈表有一些額外開銷），但是如果我們按照既定索引值對(duì)某元素進(jìn)行直接訪問(wèn)的話，顯然使用數(shù)組會(huì)更加的高效。
因?yàn)樵跀?shù)組中，我們通常可以直接計(jì)算出目標(biāo)元素在內(nèi)存中的位置，并對(duì)其進(jìn)行直接訪問(wèn)。而對(duì)于鏈表，我們需要從頭開始遍歷整個(gè)鏈表。
但是對(duì)于insert操作來(lái)說(shuō)，情況又有所不同。
對(duì)于鏈表而言，只要知道了在哪里執(zhí)行insert操作，其操作成本是非常低的。
無(wú)論該鏈表中有多少元素，其操作時(shí)間大致相同。但是，對(duì)于數(shù)組而言，每次執(zhí)行insert操作都需要移動(dòng)插入點(diǎn)右邊所有的元素，甚至在必要時(shí)需要把所有數(shù)組元素復(fù)制到另外一個(gè)更大的數(shù)組中。
也正因如此，append操作通常會(huì)采用一種被稱為動(dòng)態(tài)數(shù)組或向量的特定解決方案。
其主要思路是將內(nèi)存分配的過(guò)大一些，并且等到其溢出時(shí)，在線性時(shí)間內(nèi)再次重新分配內(nèi)存。但這樣做似乎會(huì)使得append操作變得跟insert操作一樣糟糕。
其實(shí)不然，因?yàn)楸M管這兩種情況會(huì)迫使我們?nèi)グ釀?dòng)大量的元素，但主要的不同點(diǎn)在于，對(duì)于append操作，發(fā)生這樣的可能性要小得多。
事實(shí)上，只要我們能確保每次所搬入的數(shù)組都大過(guò)原數(shù)組一定的比例（例如20%甚至100%），那么該操作的平均成本（或者說(shuō)的更確切一些，將這些搬運(yùn)開銷均攤到每次append操作中去）通常是常數(shù)的。
以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持服務(wù)器之家。如有錯(cuò)誤或未考慮完全的地方，望不吝賜教。
原文鏈接：https://blog.csdn.net/a18302465887/article/details/79311765
