第一：數據包上傳到淘寶助理
1.打開您的淘寶助理然後點擊庫存寶貝
2.
點擊工具---選擇導入資料庫
3.按照圖示選擇「合並到現在的資料庫中」選擇你說的那個userdb_bak.db
，確定之後數據即可導入助理中！
第二：修改產品具體信息（很重要修改不正確直接會導致產品無法上傳到店鋪中）
1.點擊需要修改的產品
2.修改寶貝名稱
將前面的修飾語更改成您自己店鋪的促銷活動或者直接刪除！
3.修改價格
好啦，這樣就可以上架啦
下載商品數據包
功能：下載某個供應商或某個產品系列的數據包，數據包中的寶貝類目、寶貝圖片、所在地等都已經編輯好，是可直接通過淘寶助理上傳到網店。
第一步：登陸用戶名之後進入「我的進寶」在左側「我的百寶箱」中點擊"下載商品數據包".
第二步：在搜索條中通過分類查找到需要的商品名稱，選擇右邊的「下載」，這樣就可以把需要商品的數據包壓縮文件下載下來。
第三步：數據包壓縮文件下載後進行解壓，解壓後會有一個CSV文件及商品圖片文件，如下圖：
第四步：打開淘寶助理，選擇「庫存寶貝」,
選擇「從CSV文件導入」,如下圖：
第五步：選擇剛開始解壓縮後顯示的excel表格，選擇後，打開就可以了。如圖
第六步：商品傳到淘寶助理後，選擇需要上傳的商品，然後「上傳寶貝」，這樣就可以直接傳到網店中
下載商品數據信息
功能：根據需要選擇部分商品下載商品的文字和圖片的信息。
操作方法如下：
第一步：登陸用戶名之後進入「我的進寶」在左側「我的百寶箱」中點擊「下載商品信息」。
第二步：找到您需要的商品後在商品前面的小空格中打勾，點擊「淘寶助理批量下載」，然後「保存」到一個文件夾。
第三步：淘寶助理批量下載後不要刷新，選擇「下載圖片」，然後把下載的壓縮圖片解壓縮之後和下載的商品信息放在一個文件夾中，點擊「保存」按鈕
第四步：把下載的CSV文件用EXCL表格打開，在「文件」中點「另存為」保存，如下圖：
第五步：在文件夾中把壓縮文件解壓，如下（下載下來的文件名稱不同）。
第六步：打開您的淘寶助理，選擇「庫存寶貝」。在右邊的空白處，選擇「從csv文件導入」，選擇另存過的CSV文件，這樣就可以把商品信息導入到您的淘寶助理。
第七步：點擊商品名稱之後在「編輯基本信息中」編輯這個商品的各種信息資料，比如寶貝類目、店內類目、寶貝圖片、所在地等等，編輯完寶貝基本信息之後點擊「保存」按鈕就會上傳到您的店鋪中。
注意：如果壓縮後，沒有找到csv文件。而是其他TBI格式的文件，就在第四步空白處點右鍵上面的[導入資料庫]導入那個TBI文件就可以了。
❷ 用淘寶助理上傳資料庫，圖片為何顯示不出
首先，你的問謹桐題補充啥也不能說明。
理由：淘寶更新了自己的程序，不再支持這樣的方式（這個可能喚晌耐性是有的）
其次，問題可能就不在你這邊。
理由：淘寶處理此功能的api有bug（這個可能性很大）
最後：我的觀點，
想問下，你的資料庫中存的是圖片的大二進制碼還是僅僅是一個url？
如果是url的話，地址過期和春的可能性就相當之大了。。。
但願可以有所幫助
❸ 用淘寶助理導入資料庫後,寶貝的圖片那裡顯示沒有圖片,誰能幫幫忙啊急
你是不是使用雅虎相冊
我是淘寶賣家，在3月28日相冊升級之前的一周已經在相冊首頁掛出公告了！如果你上傳到淘寶的照片是在3月28日前引用過去的，請放心，只要你在雅虎相冊不做任何更改，是不唯猛汪會有任知掘何影響的~
給你個辦法，以前那辦法行不通了，你現在可以進入雅虎再裡面找到要上傳的圖片，不是復制圖片屬性，而是要多一步，就是點擊原圖下載，然後再復制屬性，這樣就沒問題了我就這樣做，不會掛的，或者你引用到博客選項，會有個代碼，同樣指仔復制有效
❹ 淘寶資料庫怎樣批量替換圖片啊
如果是圖片上的水印是沒辦法正敏世批量舉肢替換的 除非圖片都一樣
如果圖片都一樣的話 可以在編輯描述裡面把代碼替換下拿山就成 全部一起換掉
❺ 怎麼把資料庫的圖片從淘寶助理5導入PS裡面，急求！！！謝謝
下載數據包後 解壓至文件夾中
1.打開淘寶助理，輸入淘寶帳號和密碼 2.進入昌扮淘寶助理界面後，單擊'更新數據'
3.從左邊『庫存寶貝』選項中右面單擊空白處
4.選擇空白處右鍵。找到選項 '從csv文件導入'
5.選擇解壓好的數據包。帶csv文件導入即可
6.數據成功導入助理
7.導入成功後 編運迅旅輯商品，主要對店鋪類目屬性編旁凳輯。 8.店鋪內寶貝屬性修改後，即可上傳
9.上傳數據提示信息
10. 數據提示上傳成功！
❻ 如何去除淘寶資料庫照片的水印
這跟有沒有水印沒有關系的。這是因為您引用了別人淘寶圖片空間的圖片。淘寶圖片空間具有唯一性，別人無法引用滲汪的。唯一的解決方法就是，您把原來數據包所有虛槐圖片都儲存在自己的淘寶空間，然後再利用新的叢譽仔圖片連接逐一編輯寶貝描述，才能正常發布的。
❼ 怎樣從資料庫下載圖片資料後怎樣上傳到淘寶店鋪！
網路搜下淘寶助理怎麼上傳寶貝
❽ 淘寶服裝類資料庫如何製作
我們也了解到，現在淘寶的整個的資料庫團隊在逐漸的把一些資料庫從Oracle遷移到MySQL，然後呢，把一些伺服器由小型機轉到PC server，笑爛瞎那你們整個轉變的動機是什麼?
主要是因為業務壓力給了我們最大的動力。07年我來到淘寶的時候，當時只有三個主要的資料庫，全部在小型機和存儲上面。以當時的壓力來看，它跑起來是非常順利的，而且大家也知道小型機它從Unix操作系統到硬體，穩定性都會比PC server其實要高很多，當時的情況下淘寶用小型機是一個非常自然的選擇。
從07年開始淘寶的業務量保持每年自然翻一番的增長，資料庫質量感覺到非常大的壓力。那麼前端業務量增長一倍，在資料庫上有可能增長是好幾倍，它有一個放大效應在里邊。當時我們第一步能夠想到很自然的架構，就是把三個資料庫拆成更多的資料庫，或每一個資料庫支持一個比較單一的業務。比如用戶、商品和交易，都會分成獨立的資料庫，然後放到獨立的小型計算中去，這是我們08年做的很大的事情就是垂直拆分，然後08年的業務我們就頂住了。
當時我們就預估09年、10年會有更大的壓力增長，這個時候我們應該怎麼辦？當時我們從業界能看到很多的經驗分享，包括eBay、亞馬遜這些國外的大公司，他們的經驗分享裡面，水平拆分是我們資料庫漲到一定程度後的架構選擇。我們從Oracle到MySQL轉移，主要是用水平拆分，這是我們未來的一個弱點，那水平拆分後機器、資料庫的數量都會多很多，那Oracle它本身的成本也是我們考慮的一個重要因素，所以當時從成本考慮的話，那個時候我們自然會選擇用MySQL資料庫。
給我們再簡單總結一下這幾年，碰空淘寶整個資料庫的演變過程?
剛才說到08年我們做完垂直拆分以後，09年到今年我們主要做的工作其實就是水平拆分。今年在十月份之前我們全部完成了淘寶最核心的三個系統：交易資料庫、商品資料庫和用戶資料庫的水平拆分。所以到「雙十一」之前，在我們內部采訪中，我一直跟采訪人員說，當時資料庫情緒穩定。基本上我們沒有做什麼事情，只是在不停的看報表，看數據，然後很開心的看到交易曲線以超過45度的趨勢往上漲。
那前期還是做了非常完善的准備。據我們了解在整個從小型機到PC server的遷移，包括從Oracle到MySQL資料庫的遷移，你們在做這個事情的時候，都做過好幾個月的壓力測試。你講講這個背景和故事。
是這樣的，今年我們年初決定，我們商品庫從小型機遷到PC server上面去，這是淘寶壓力最大的一個資料庫，當時是用四台小型機加兩個歷扮高端存儲來支撐的。要把這么大一個資料庫進行遷移，我們心裏面也是沒有底的，因為不知道要多少台PC server能夠支撐，需要什麼樣的配置來支撐這個壓力？當時我們能夠想到一個很直觀的想法就是模擬線上完全一樣的壓力，甚至加上幾倍的壓力來測它的極限值。
我們和開發團隊、我們的性能測試團隊，加上DBA團隊和ops團隊，成立了一個非常大的項目組，然後做了接近兩個月的性能測試，在整個測試過程中發現了非常多的問題，包括我們給Oracle、MySQL等廠商都提交了很多Bug，有些Bug也得到廠商回應，進行修復。
那整體的轉變的過程到現在進行到了什麼樣的程度？包括你在整個轉變的過程中遇到哪些問題?
我們現在最核心的用戶資料庫今年已經徹底完成了從小型機、存儲和Oracle切入到PC server加MySQL的架構。
我們內部有一個提法叫做去O、去I、去E，其實就是我們要從高端硬體Scale up模式到低端硬體的Scal out水平擴展的模式，這是淘寶內部最大最核心的系統，今年已經順利完成了全部區的水平擴展。其他幾個系統，比如說交易和商品已經完成了一部分，完成了水平拆分的一部分，但是沒有達到我們希望的進度，這可能是明年我們需要做的事情。
在轉型過程中主要遇到哪些問題?
讓我們覺得比較大的問題就是我們從可靠的小型機遷移到大規模，大數據量的PC server上來，從架構上就對我們就是一個非常大的挑戰。大家都知道，每一個PC server的穩定性肯定和單台小型機會有一定的差距，再加上我們一個機群有可能是32台或者64台PC server。每一台PC server即使有四個9的可用性，但如果我們整個系統合在一起，可能它最後的兩個9的可用性都達不到。這就需要我們從軟體層、架構層要做非常多的改進，能夠要讓單點的一些失效對整體的系統不造成任何影響，因為我們和架構部門、開發部門一起做了很多事情，才能保證我們的集群穩定上線。
其實「雙十一」這個時間應該說是對過去的技術轉變的檢驗，現在回頭來看，這個檢驗的結果怎麼樣?
當時是有點提心吊膽的，之後又覺得相對來說今年我們做的很多事情還是非常成功的。但是現在再回頭仔細想想還是有點後怕，「雙十一」那天的凌晨零點不是有一次Ipad的秒殺嗎，當天晚上我們都在線上觀察數據，在零點的一瞬間，就看到所有資料庫指標已經達到了以前正常時候最高峰的指標，有些甚至還超過了。
當天晚上睡覺的時候心裡就有點在打鼓：才零點就這個樣子了，明天下午明天晚上最高峰的時候我們應該怎麼渡過？所以第二天早上八點多的時候我們一進到指揮部裡面就看到所有的指標， 包括CDN的指標、各個業務線的指標、資料庫的指標都是噌噌的往上漲，這時心裏面其實是很忐忑不安的。
但是我們比較放心的是這三大核心系統，商品、用戶和交易，在我們今年所有的水平擴展項目做完了以後，比如說商品功能做完了以後，從我們的機械壓測裡面它是有十倍的流量的，所以當天百分之一百，百分之兩百的流量基本上對資料庫沒有造成太大的影響，所以當時還是很開心的看到這個指標快速的往上漲，希望交易能夠通過10個億、20個億，我覺得都是能夠承受的。
那對於整個資料庫架構的演進下一步有什麼打算?
下一步其實就是剛剛說的我們有幾個核心系統還沒有完全的做到這個水平擴展，加上「雙十一」那天我們還是有一個小驚險：我們有一個資料庫，跟交易核心有一點點聯系的，但它還是放在小型機上面，當時已經提前為它准備了百分之一百的餘量，就是說它可以承擔平時最高壓力的兩倍。
但是那天已經達到平時最高壓力的1.8倍左右的時候，把我們嚇出了一身冷汗。如果當時淘寶的交易最高峰的流量再增長20%的話，有可能資料庫就會到瓶頸了。所以我們明年是要把更多這種Scale up能夠看到天花板的資料庫全部要拆分成水平庫存這種資料庫。
那你剛才所提到的去Oracle，去小型機，去高端存儲，這個「三去」的整體思路給淘寶網帶來了哪些經濟上的效應?
當時我們知道小型機和存儲的價格是非常昂貴的，還是拿我們剛才說壓力最大的商品資料庫舉個例子，當初我們資料庫是用了四台高端的小型機，兩套高端的存儲，成本加起來起碼都是三千萬以上。那目前我們用的是32台PC server來搭建的一個機群，價格也就是300萬~500萬的級別。相對來說我們做完這個事情以後，解決了兩三千萬的硬體成本。
這樣來講，整體的經濟效益還是非常不錯的。但是其實剛才我們在前期溝通的時候也提到，你要從Oracle轉到MySQL，包括從小型機轉到PC server，其實裡面還是會遇到蠻多問題的，包括它的不穩定性等等，那對於這一方面你有沒有什麼經驗可談?
在這一方面，我覺得有兩個很重要的因素。第一個是我們需要和我們的開發前端應用架構部門能夠緊密的合作，能夠讓我們的應用融入剛才說的整個機群的單點失效和容災的問題。都需要我們和架構部門一起來考慮的；第二個比較大的經驗就是目前我們在做的，深入研究MySQL的源代碼。我們從研究和壓力測試的過程中，發現MySQL它本身代碼的一些缺陷，可能在高並發大壓力下會有很多隱藏的Bug。
在我們最近的這次測試當中，我們還發現了Facebook發布的FlashCache二級緩存的軟體，當時我們是測出它一個非常大的Bug：並發壓力非常大的情況下，它會導致MySQL成為一個僵屍進程。我們發現了以後，很快反饋給Face book，然後Face book很快就修復了這個問題，這也是我們對使用開源軟體帶來更大的一個信心，就是開源能夠在全球得到更多的支持，大家都能夠從原代碼層面來解決更深層次的一個問題。
我想這也可能是淘寶技術團隊現在那麼開放，那麼注重開源的動力之一。那如果說想對MySQL的一些核心代碼做編譯，就需要對人才的儲備，包括各方面資源整合的要求還是蠻大的，那你在這方面有沒有什麼感觸?
說到人才這個話題，08年的時候，淘寶當時准備大規模的往MySQL方向上轉，我們內部也是有一些置疑的聲音。他們說淘寶DDA團隊以前都是在Oracle方面比較專精，在業界來說，淘寶的DDA團隊在Oracle方面更加有名氣一些。所以我們內部有置疑的聲音。就是說你們有MySQL專家嗎，MySQL出問題了以後能很快的解決嗎？所以從08年到現在，我們慢慢的一路走過來，內部培養了很多的MySQL的人才，包括這幾年我們的應屆生的成長，再加上我們從外部招到一些專家，我們對MySQL的理解已經越來越深。
剛才說到，我們已經能夠給MySQL打Patch，已經能夠給MySQL report這些Bug。到現在為止，我覺得MySQL的成長已經達到了非常高的一個程度，我們對MySQL已經越來越有信心，但是未來淘寶的MySQL肯定是要做得越來越大的，淘寶還有很多小型機上面擴展不太容易的系統需要遷移到可擴展的機群上面來，但我們也希望業界能夠有更多的MySQL夥伴加入我們，和我們一起來做這么一件非常有意義的事情。
我想能夠加入到淘寶的技術團隊，去經歷那麼多有大交易量的技術實踐還是非常寶貴的。另外一個問題就是雖然說現在我們用的越來越多的是MySQL，但是現在大家也知道MySQL已經被Oracle收購了，那對像淘寶這樣的團隊有什麼影響呢?
大家都知道MySQL其實是基於GPL的協議來開源的軟體，那淘寶在使用過程中，前期是已經考慮到一些風險。所以我們所有的MySQL都是自己來做編譯做優化的，而且我想MySQL被Oracle收購了以後，現在看起來Oracle應該是給MySQL在開發這方面是提供了更大的幫助，像之前在Sun的時候，MySQL的版本相對來說是比較混亂的，包括我們現在在用的5.0和5.1的正式版本，最近還有包括開發方面就還有兩個，一個6.0，一個5.4，這些特性會互相交織在一起，讓我們選擇的時候也有點不知道到底選哪個版本會更好一點。但現在Oracle收購MySQL以後，他把5.4跟6.0這些版本已經合成了一個比較規范的5.5的版本，並且為它制訂了很好的一個milestone15：31，未來要怎麼發展這個里程碑，M1、M2、M3、M4這種發展方向，而到現在為止這個5.5已經發展到5.6、5.7的版本，而且已經是IC版本了，很快就要GA了，那我想這對於MySQL來說應該是一個好消息。我們可以用到更多更穩定的新特性， 5.5版本里有幾個新的特性是我們非常關注的，比如Google已經達到英文15：57這個pach，所以我們覺得對我們未來的這個MySQL這個系統非常有用的一個功能。那我們也等著Oracle的5.5這個版本能夠盡快的GA出來。