其實(shí)mysql培訓(xùn)文檔的問題并不復(fù)雜，但是又很多的朋友都不太了解數(shù)據(jù)庫培訓(xùn)，因此呢，今天小編就來為大家分享mysql培訓(xùn)文檔的一些知識，希望可以幫助到大家，下面我們一起來看看這個問題的分析吧！
pymysql 沒反應(yīng)
如果pymysql沒反應(yīng)，可能的原因：
第一，有可能是只安裝了pycharm，沒有裝anaconda，沒有給編輯器添加解釋器，所以運(yùn)行不了代碼。
第二，有可能是代碼錯誤，如果下邊爆紅了，而且會有警告等詞語，代碼也無法運(yùn)行。
第三，有可能是編輯器內(nèi)部環(huán)境錯誤，沒有添加編譯環(huán)境。
sql查詢腳本怎么寫
有庫，有前人留下的幾個文檔也沒用。
得有書，買一本mysql的書，從第一章開始下載安裝mysql,建庫，到最后一章，把庫刪掉。
再不用書，建庫，建表，插數(shù)據(jù)，優(yōu)化查詢......，刪庫
搞得很6的時候，就出師了。
提示：
?不要使用正式庫操作。在自己電腦上搞個學(xué)習(xí)庫。
?稍微明白了一些套路的時候，復(fù)制正式庫結(jié)構(gòu)，搞一個測試庫。在正式庫上動手術(shù)前，先在測試庫上搗鼓搗鼓，這樣可以避免99%的操作失誤。
?正式庫不保存密碼，測試庫保存不保存密碼隨你
?所有操作，先寫成腳本保存到文本文件上。
?在update語句前，先寫sql語句帶update的條件預(yù)判結(jié)果。
?……，還有很多，有人看的話，以后再補(bǔ)充。
如何編輯mysql中events的executeat如何使用
一次意外的發(fā)現(xiàn)創(chuàng)建完Event之后，information_schema.events和mysql.event表中execute_at和last_executed字段均相差8個小時，mysqld實(shí)例的時區(qū)為：
測試過程
創(chuàng)建測試數(shù)據(jù)庫
創(chuàng)建測試數(shù)據(jù)表
創(chuàng)建Event
執(zhí)行SQL語句查詢mysqld實(shí)例的時區(qū)和時間
執(zhí)行SQL語句查詢information_schema.events表和mysql.event表中execute_at和last_executed字段值
問題原因
為了確保Event的執(zhí)行不受時區(qū)的影響，使得Event可以準(zhǔn)確執(zhí)行，MySQL將mysql.event表的事件調(diào)度時間（execute_at和last_executed）轉(zhuǎn)換成UTC時間。
文檔描述：
TimesintheONSCHEDULEclauseareinterpretedusingthecurrentsessiontime_zonevalue.Thisbecomestheeventtimezone;thatis,thetimezonethatisusedforeventschedulingandisineffectwithintheeventasitexecutes.ThesetimesareconvertedtoUTCandstoredalongwiththeeventtimezoneinthemysql.eventtable.Thisenableseventexecutiontoproceedasdefinedregardlessofanysubsequentchangestotheservertimezoneordaylightsavingtimeeffects.
如何將Oracle遷移至mysql
從Oracle遷移到MySQL需要考慮的事情其實(shí)遠(yuǎn)比我們要理清數(shù)據(jù)類型轉(zhuǎn)換這些技術(shù)細(xì)節(jié)要多，也更重要。
有兩個問題需要前置考慮：
為什么要從Oracle遷移出去？
為什么要遷移到MySQL
如果解答了上述的兩個問題，也就基本理順了整個事情的脈絡(luò)，我會本著基本客觀的態(tài)度來說明。
問題1：為什么要從Oracle遷移出去？
這件事情從行業(yè)的實(shí)踐來看（主要是說互聯(lián)網(wǎng)行業(yè)），絕對不是先從技術(shù)可行性觸發(fā)，而是從業(yè)務(wù)可行性來入手，歸根結(jié)底，主要的出發(fā)點(diǎn)就兩個字：成本。
MySQL開源免費(fèi)，更重要的是行業(yè)實(shí)踐驗(yàn)證充分，所以它具有得天獨(dú)厚的優(yōu)勢。阿里多年前的去IOE風(fēng)風(fēng)火火，儼然成為了行業(yè)的標(biāo)桿。
成本的事情很微妙，三言兩語說不清。舉例來說，你可以使用Office來辦公，當(dāng)然你可能考慮買授權(quán)或者綠色版激活，但是如果使用WPS就是名正言順的事情，當(dāng)然功能上是和Office有一些差距，但是不會存在一些模糊的邊界。
從業(yè)務(wù)的另一個維度來看，試想我們所接觸的互聯(lián)網(wǎng)行業(yè)，很多業(yè)務(wù)除了充值和錢相關(guān)的業(yè)務(wù)，其實(shí)對于數(shù)據(jù)完整性一致性的要求就會降低一個維度，很多時候錢能解決的問題都不是問題，比錢更重要的是什么，我覺得應(yīng)該是安全，安全包括生命安全，行業(yè)安全，系統(tǒng)安全，這些絕對不允許出一些重大問題的，這些影響面太大，比如醫(yī)院醫(yī)生給患者開藥的數(shù)據(jù)，這些影響面是很大的，一旦出問題很容易成為公眾事件。而以金融級業(yè)務(wù)作為一個分界點(diǎn)，之上的是安全領(lǐng)域，之下的領(lǐng)域其實(shí)就是一些可選擇的空間了，這些空間很大。選擇商業(yè)的一個原因也在此，有技術(shù)兜底，這些成本對企業(yè)來說也是需要和廠商的綁定關(guān)系。稀里糊涂硬上，出了問題找不到專業(yè)的快速支持，那就悲劇了。
然后是開源定制，其實(shí)很多開源技術(shù)的開源協(xié)議是有差別的，我們采用開源技術(shù)也需要考慮這些協(xié)議的邊界和適用范圍。
所以到此需要明確的是：
1.成本因素需要權(quán)衡，絕對不是非黑即白的事情
2.遷移到MySQL其實(shí)不是終極解決方案,只是一種可選的方案
3.對開源技術(shù)積累足夠，技術(shù)把控能力要強(qiáng)
4.遷移的本質(zhì)是找到最適合的業(yè)務(wù)場景，而不是為了技術(shù)實(shí)現(xiàn)而實(shí)現(xiàn)
對于第4點(diǎn)，舉個例子，Oracle從性能上是毫無疑問的，但是如果有海量的讀請求，其實(shí)就不適合Oracle來扛了，當(dāng)然也不適合用MySQL,可能Redis的方案會更好一些。
問題2：為什么要遷移到MySQL
要回答這個問題，其實(shí)我們的主線就是MySQL可以做什么。
第一還是成本，開源免費(fèi)，方便定制，MySQL的可選方案可絕對不只有社區(qū)版，還有一系列的分支，比如Percona分支，MariaDB分支，存儲引擎InnoDB,MyRocks等統(tǒng)統(tǒng)都是免費(fèi)可選。
第二是MySQL效率高，足夠輕量級。MySQL的效率從使用上來說，學(xué)習(xí)周期會很短，容易上手，而且對于系統(tǒng)的資源要求不高。
第三是水平擴(kuò)展能力，把Oracle比作地鐵，MySQL比作公交車會更容易理解，我們可以很輕松的加開公交專線，但是加開地鐵線路那就完全不同了。我覺得這是遷移到MySQL的一個核心點(diǎn)，這也就是為什么很多互聯(lián)網(wǎng)的MySQL規(guī)模動輒幾百幾千了，爆發(fā)式增長的業(yè)務(wù)，MySQL擴(kuò)展能力了不是體現(xiàn)在MySQL數(shù)據(jù)庫本身，而是對于架構(gòu)的擴(kuò)展性上，而這也就是為什么很多MySQLDBA比較貴的一個原因。
第四是復(fù)制，這是MySQL相比Oracle的一個亮點(diǎn)，如果需要做跨數(shù)據(jù)中心的復(fù)制，允許存在一定的延遲，使用MySQL原生的復(fù)制方案是一件很容易的事情，MySQL支持很多不同維度的復(fù)制方案。
第五是業(yè)務(wù)輕依賴，這個可以分為兩個維度來說。一個是功能限制，一個是性能限制。這本身是MySQL功能和性能上的缺失，但是反而是一個優(yōu)點(diǎn)因?yàn)橐畏植际叫枨螅枰獦I(yè)務(wù)對數(shù)據(jù)庫的依賴要更輕巧一些，原本支持不好的存儲過程就可以很自然的弱化了。
第六是開源帶來的生態(tài)體系，開源紅利帶給企業(yè)的是很多的技術(shù)方案選擇，讓原本需要花錢買的事情變成了我們干我們用。
問題3：從Oracle遷移到MySQL需要考慮的事情
首先是架構(gòu)的差異，在oracle和MySQL里面的差異還是比較大的，當(dāng)然Oracle里面也是可以使用同義詞的架構(gòu)來實(shí)現(xiàn)類似MySQL的訪問模型的。
數(shù)據(jù)類型的差異其實(shí)是比較具體的技術(shù)細(xì)節(jié)，我舉一些補(bǔ)充的。
oracle里面的Null和空串都可以按照null來處理，但是MySQL里兩者是不同的。
oracle表名，用戶名都是有長度限制，在30個字符以內(nèi)，在MySQL里長度要大得多，尤其是表名就需要注意了。
oracle里會默認(rèn)統(tǒng)一按照大寫來處理，MySQL里面默認(rèn)是大小寫敏感的。
對于MySQL類型在MySQL里需要考慮的細(xì)節(jié)較多，比如數(shù)值型，oracle里面number搞定，MySQL有一系列的數(shù)值類型可以選擇，不建議大一統(tǒng)的bigint適配所有需求。
要更清晰的回答注意事項(xiàng)，可以歸類為一個問題：MySQL相比Oracle少了些什么?
性能上肯定有差異，我們主要理一理功能上的。比較的原則不是說oracle有一定要MySQL有，而是從一些使用場景上來說更好的使用特性。
存儲過程支持有限，這是很多企業(yè)的技術(shù)債，處理好了是坦途，處理不好是大坑。比如存儲過程，硬要用存儲過程調(diào)用來對接，后期后患無窮。
沒有同義詞
沒有dblink，這個特性MySQL里不支持其實(shí)是件好事，杜絕了那種跨庫關(guān)聯(lián)的需求。
沒有sequence，這個MySQL的自增列完全可以彌補(bǔ)。
沒有物化視圖，難以實(shí)現(xiàn)增量刷新的需求。
分區(qū)表有，但是很少用
優(yōu)化器薄弱，多表關(guān)聯(lián)，HashJoin在MySQL里還是一個弱項(xiàng)。
索引的差異，覆蓋索引的實(shí)現(xiàn)兩者差異也很大。
綁定變量的性能差異不大，Oracle里面敏感的綁定變量問題在MySQL里不是問題。
性能工具，MySQL里面的性能工具還是比較少的，而且粒度和效果有限。
小結(jié)一下：
遷移的本質(zhì)是找到最適合的業(yè)務(wù)場景，而不是為了技術(shù)實(shí)現(xiàn)而實(shí)現(xiàn)
oracle修改成mysql需要更改的配置項(xiàng)
當(dāng)將oracle遷移到mysql時，需要更改以下配置項(xiàng)：
1.數(shù)據(jù)類型：mysql和oracle使用不同的數(shù)據(jù)類型。您需要將列的數(shù)據(jù)類型從oracle轉(zhuǎn)換為對應(yīng)的mysql數(shù)據(jù)類型。
2.主鍵：mysql中的主鍵定義方式與oracle不同。您需要更改表的主鍵定義以適應(yīng)mysql。
3.自動遞增列：如果表中有自動遞增列，您需要使用mysql的自動遞增關(guān)鍵字來定義該列。
4.索引：您需要將表的索引定義從oracle語法轉(zhuǎn)換為mysql語法。
5.存儲過程和函數(shù)：oracle和mysql使用不同的存儲過程和函數(shù)語法。您需要更改存儲過程和函數(shù)的語法以適應(yīng)mysql。
6.觸發(fā)器：oracle和mysql的觸發(fā)器語法和功能也有所不同。您需要更改觸發(fā)器定義以適應(yīng)mysql。
7.sql語法：oracle和mysql的sql語法也有細(xì)微差異。您需要根據(jù)mysql的語法要求更改sql語句。
注意：這只是一些常見的改動，具體取決于您的應(yīng)用程序和數(shù)據(jù)庫架構(gòu)。在進(jìn)行遷移之前，建議詳細(xì)了解mysql的特性和限制，以確保正確地進(jìn)行配置項(xiàng)的更改。同時，最好先進(jìn)行充分的測試和驗(yàn)證，以確保數(shù)據(jù)的正確性和應(yīng)用程序的穩(wěn)定性。
mysql培訓(xùn)文檔的介紹就聊到這里吧，感謝你花時間閱讀本站內(nèi)容，更多關(guān)于數(shù)據(jù)庫培訓(xùn)、mysql培訓(xùn)文檔的信息別忘了在本站進(jìn)行查找哦。
