雜學: 7月 2018

Hello. I am Matti. I am Finnish. I am 18 years old.
Minä olen Matti. Minä olen suomalainen. Minä olen kahdeksanoista vuotias.

Nice to get to know you, Matti. I’m Michael. I’m 17 years old.
Hauska tutustua, Matti. Minä olen Michael. Minä olen seitsemäntoista vuotias.

Where do you originate from, Michael?
Mistä maasta sinä olet kotoisin, Michael?

I’m from England.
Minä olen kotoisin Englannista.

Why are you in Finland?
Miksi sinä olet Suomessa?

I have a Finnish girlfriend.
Minulla on Suomalainen tyttöystävä.

Hey Hanna!
Hei Hanna!

Hi! How is it going?
Hei! Miten menee?

Good thanks. And you?
Hyvin kiitos. Entä sinulle?

Thanks, good.
Kiitos hyvin.

What’s your name?
Mikä sinun nimi on?

I am Yuhua.
Minä olen Yuhua.

Where do you come from?
Mistä sinä olet kotoisin?

I come from China.
Minä olen kotoisin kiinasta.

Where do you live?
Missä sinä asut?

I live in Tampere.
Minä asut Tampereella.

What language do you speak?
Mitä kieltä sinä puhut?

I speak Chinese.
Minä puhun kiinaa.

Do you speak Finnish?
Puhutko sinä suomea?

A little.
Vähän.

explain SELECT user_id, user_loginID, user_pic 
FROM users 
WHERE user_loginID='user1234' AND user_password_encrypted='aaa1234' 
AND user_status=1;
+----+-------------+-------+-------+-------------------------------------------------------------+---------------------+---------+-------+------+-------+
| id | select_type | table | type  | possible_keys                                               | key                 | key_len | ref   | rows | Extra |
+----+-------------+-------+-------+-------------------------------------------------------------+---------------------+---------+-------+------+-------+
|  1 | SIMPLE      | users | const | user_loginID_UNIQUE,loginID_pw_index,loginID_emailcrc_index | user_loginID_UNIQUE | 50      | const |    1 | NULL  |
+----+-------------+-------+-------+-------------------------------------------------------------+---------------------+---------+-------+------+-------+
1 row in set (0.00 sec)

以上面的SELECT為例，EXPLAIN後的資料大約有這些欄位：

id：
MySQL Query Optimizer 選定的執行計劃中查詢的序列號。
表示查詢中執行select子句或操作表的順序,id 值越大優先級越高,越先被執行。
id 相同,執行順序由上至下。

select_type：
查詢的類型

查詢的類型	說明
SIMPLE	簡單的select 查詢,不使用union 及子查詢
PRIMARY	Content Cell 最外層的select 查詢
UNION	UNION 中的第二個或隨後的select 查詢,不依賴於外部查詢的結果集
DEPENDENT UNION	UNION 中的第二個或隨後的select 查詢,依賴於外部查詢的結果集
SUBQUERY	子查詢中的第一個select 查詢,不依賴於外部查詢的結果集
DEPENDENT SUBQUERY	子查詢中的第一個select 查詢,依賴於外部查詢的結果集
DERIVED	用於from 子句裡有子查詢的情況。MySQL 會遞歸執行這些子查詢, 把結果放在臨時表裡
UNCACHEABLE SUBQUERY	結果集不能被緩存的子查詢,必須重新為外層查詢的每一行進行評估
UNCACHEABLE UNION	UNION 中的第二個或隨後的select 查詢,屬於不可緩存的子查詢

table：
關連到的資料表

type：
使用關聯查詢的類型
(效率由好至壞排序)

關聯查詢的類型	說明
System	表僅有一行(=系統表)，此為const連接類型的特殊情況
Const	資料表中的一個記錄的最大值能夠符合這個查詢。因為只有一行，這個值就是常數，因為MySQL會先讀這個值然後把它當做常數
eq_ref	MySQL在連接查詢時，會從最前面的資料表，對每一個記錄的聯合，從資料表中讀取一個記錄，在查詢時會使用索引為主鍵或唯一鍵的全部
ref	只有在查詢使用了非唯一鍵或主鍵時才會發生。連接不能基於關鍵字選擇單個行,可能查找到多個符合條件的行。叫做ref 是因為索引要跟某個參考值相比較。這個參考值或者是一個常數,或者是來自一個表裡的多表查詢的結果值
fulltext
ref_ or_ null	同ref, 但是MySQL 必須在初次查找的結果裡找出null 條目,然後進行二次查找
index_merge	說明索引合併優化被使用了
unique_subquery	在某些IN 查詢中使用此種類型,而不是常規的ref:value IN (SELECT primary_key FROM single_table WHERE some_expr)
index_subquery	在某些IN 查詢中使用此種類型, 與unique_subquery 類似,但是查詢的是非唯一性索引: value IN (SELECT key_column FROM single_table WHERE some_expr)
range	只檢索給定範圍的行,使用一個索引來選擇行。key 列顯示使用了哪個索引。當使用=、 <>、>、>=、<、<=、IS NULL、<=>、BETWEEN 或者IN 操作符,用常量比較關鍵字列時,可以使用range
index	全表掃描,只是掃描表的時候按照索引次序進行而不是行。主要優點就是避免了排序, 但是開銷仍然非常大
ALL	針對每一筆記錄進行完全掃描，此為最壞的情況，應該盡量避免

possible_keys：
可能使用到的索引，從WHERE語法選擇出一個適合的欄位

key：
MySQL 實際從possible_key 選擇使用的索引。
如果為NULL,則沒有使用索引。
很少的情況下,MYSQL 會選擇優化不足的索引。
這種情況下,可以在SELECT 語句中使用USE INDEX (indexname)來強制使用一個索引
或者用IGNORE INDEX(indexname)來強制MYSQL 忽略索引

key_len：
使用索引的長度，長度越短，準確性越高

ref：
顯示那一列的索引被使用，一般是一個常數(const)

rows：
MySQL認為必須檢查的用來返回請求數據的行數，可以簡單的把rows視為執行效能，
越少越好

Extra：
MySQL用來解析額外的查詢訊息
(效率由好至壞排序)

額外的查詢訊息	說明
Using where	使用WHERE語法中的欄位來返回結果
Using index	返回的資料是從索引中資料，而不是從實際的資料中返回，當返回的資料都出現在索引中的資料時就會發生此情況
Using filesort	表示MySQL會對結果使用一個外部索引排序,而不是從表裡按索引次序讀到相關內容。可能在內存或者磁盤上進行排序。MySQL 中無法利用索引完成的排序操作稱為“文件排序”。MySQL必須進行額外的步驟來進行查詢
Using temporary	此為MySQL必須建立一個暫時的資料表(Table)來儲存結果，此情況會發生在針對不同的資料進行ORDER BY和GROUP BY。

SELECT * FROM demotable ORDER BY id LIMIT 2,4

LIMIT後面接 [index, count]:

Index：從哪個index開始傳回，Index是從0開始算，若以這個範例來看，資料會由第3筆資料開始回傳(2+1=3)
count：由index開始，總共要傳回幾筆資料，以此範例來說，總共會傳回第3、4、5、6共四筆資料

SELECT * FROM demotable ORDER BY id LIMIT 4 OFFSET 2

有些SQL的資料庫不支援[index,count]的格式(例如PostgreSQL)，必需要用OFFSET來取代，OFFSET可以把它想成要略過筆數，以OFFSET 2為例，便可想成在找到的資料筆數中略過前二筆，即是由第三筆開始回傳。
但是隨著OFFSET (index) 的數量越大，其檢索性能便會越差。例如頭10萬或30萬筆數只需0.01秒，而去到50萬筆以上則需要3秒以上。為什麼會出現這樣的時間差異呢？其原因就在於表的掃描！假設我們要去執行LIMIT 5 OFFSEST 200000的資料讀取，MySQL便需要掃描出滿足條件的200005(200000＋5）行的資料，然後再扔掉前面的200000行，返回最後的5行，OFFSET愈大當然會掃描得愈多。因此針對OFFSET問題我們需作出更多的優化考慮。

優化前SQL:

SELECT * FROM demoTable ORDER BY time
LIMIT 200000,5

優化後SQL:

SELECT * FROM demoTable
JOIN 
(
  SELECT id FROM DemoTable ORDER BY times
  LIMIT 200000,5
)
USING (id)

另外，IN也是其中一個方法，但可惜我的MySQL還未更新。

SELECT * FROM demoTable
WHERE id IN
(
  SELECT id FROM demoTable ORDER BY times
  LIMIT 200000,5
);
//ERROR 1235 (42000): This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery’

這個是不用OFFSET直接用WHERE來指向讀取index位置，但不適用於Time或Like Count的排序。

SELECT id
FROM demoTable
WHERE id > 200000
ORDER BY id desc
LIMIT 6 OFFSET 0

分別在於，優化前的SQL需要浪費更多IO，而優化後的SQL則是預先讀取Primary key，後再以Primary key讀取數據，使其聽取速度加快。

首先是只讀取Primary key的部分。

除了INDEX會影響讀取的速度外，讀取的欄位也會一定程度的影響（有時遠比INDEX所帶來的影響更甚！），欄位讀取愈多愈會加重CPU以及內存的負擔，大大減低了整體IO效能。

SELECT * FROM demotable ORDER BY time DESC LIMIT 200000,5; //執行2秒
SELECT id FROM demotable ORDER BY time DESC LIMIT 200000,5; //執行0.5秒

而之後的部分便是以Primary Key來讀取真正需要的資料。
由於Subquery已幫我們篩選出了5筆資料的id，而且還是以primary key 當條件，讀取起來並不會費事。

整體而言，我們只需處理好subquery𥚃的index就可以了。
但需要注意的是MySQL會遞歸執行的subquery結果放在臨時表裡，因此太大的LIMIT也會影響效能。而且subquery本身也讓SQL的執行更加複雜化，太多的subquery反而不能達到預期效果。

1. 悲観的ロック

悲観的ロックとは、他の処理と競合してはならないトランザクションにおいて、開始時に更新の抑止がされていないことを確認後（抑止されている場合は解除されるまで待機するか、エラーとして処理をあきらめるか）他からの更新を抑止し、完了する際に抑止情報を解除することです。これは排他制御の一種です。

今の「select for update」はこういう概念です。資料処理の安全と統一性のため保守的なやり方ですが、効率的には良くないです。デッドロックを行う可能性も増えるし、ロック自身でもデータベースに負担を掛けます。また、ロック解除されるまでは待機するので、資料処理の並行性も影響されます。それで、悲観的ロックはトランザクションが短く、頻繁に更新され、なおかつ同時更新が多発するような場合しか使う最終手段です。

メリット

資料処理の安全と統一性を守る

デメリット

デッドロックを行う可能性も増える
ロック自身でもデータベースに負担を掛ける
ロック解除されるまでは待機する (トランザクションが短いので、待機時間はほぼない)

2. 楽観的ロック

悲観的ロックとは、他の処理と競合してはならないトランザクションにおいて、開始時には特に排他処理など行なわず、完了する際に他からの更新がされたか否かを確認し（データのtimestampやversion idで確認する）、もし他から更新されてしまっていたら自らの更新処理を破棄し、エラーとすることです。

ロックを行なわず直接にデータを更新するので、デッドロックを行うことやデータベースに負担を掛けるを回避できます。資料処理の並行性も守れます。しかし、これは競合激しくないトランザクションしか使えます。同時にデータを読んで更新する場合はまたエラーが発生します。だが、今回はtimestampで確認するので、そういう可能性が低いと思います。悲観的ロックと比べて、悲観的ロックは更新頻度がそれほど高くなく、同時に編集するユーザーが少ないような場合で使う手段です。

メリット

デッドロックを行うことを回避できる
データベースに負担を掛けない
資料処理の並行性を守れる

デメリット

同時にデータを読んで更新する場合はエラーが発生する(Timestampやversionをチェックしても解決できない)

循例講講，建議大家看看這個官網的說明吧。

點一下「讚」按鈕會對網頁的特定內容「按讚」，同時將內容分享到 Facebook。您也可以在「讚」按鈕旁邊同時顯示「分享」按鈕，如此可以讓用戶在分享內容時加入個人訊息，並且自訂分享對象。https://developers.facebook.com/docs/plugins/like-button

之後廢話少說，直接去懶人Copy-Paste！！

Step 1) Blogger > 範本 > 編輯HTML

Step 2) 在<body>與</body>中間貼上以下的code

<script>
  window.fbAsyncInit = function() {
    FB.init({
      appId      : '****************',
      xfbml      : true,
      version    : 'v2.3'
    });
  };

  (function(d, s, id){
     var js, fjs = d.getElementsByTagName(s)[0];
     if (d.getElementById(id)) {return;}
     js = d.createElement(s); js.id = id;
     js.src = "//connect.facebook.net/zh_TW/sdk.js";
     fjs.parentNode.insertBefore(js, fjs);
   }(document, 'script', 'facebook-jssdk'));
</script>

※　appId 是在 https://developers.facebook.com/ 登記時取得的No.

Step 3) <data:post.body/>後面貼上以下的code

<div class="fb-like" data-layout="button_count" data-action="like" data-show-faces="false" data-share="false" expr:data-href='data:post.canonicalUrl'></div>
<div class="fb-share-button" data-layout="button_count" expr:data-href='data:post.canonicalUrl'></div>
<div class="fb-send" expr:data-href='data:post.canonicalUrl'></div>
<div class="fb-comments" expr:data-href='data:post.canonicalUrl' data-numposts="5" data-colorscheme="light"></div>

1.「対象の定義」

例ー：卵を持っていますか

例二：卵がありますか

私の視点から見ると、例ーと例二は全く同じ意味ですが、

なんで例ーは「を」、なんで例二は「が」にしますだろう？

実際、日本語の中では、「人」（生き物）以外「もの」（死物）も一つの対象となります。

「卵を持っていますか」ここは「あなたは」という略した意味でもあります。

だから、例ーは「人」を対象にする文章です。

「卵がありますか」、ここは「卵」というものだけを対象にするので、

「人」という存在がありません。

しかし、どんな時に「人」を対象にするか、どんな時に「もの」を向かうか、

自動詞と他動詞の使い方も違います。

2.「自動詞と他動詞の定義」

自動詞は、人為的なことではなくで、意図を持ってない「自然的に発生する」ことです。

他動詞は、ある人がある目的を意識して、意図を持っている行動です。

そして、自動詞を使う時は「が」をつける、他動詞を使う時は「を」をつけます。

だから、そう結論があります。

例三：火が消えました。

例四：私は火を消しました。

例三の中には、「人」という存在がありません。

「火が消える」のは自然的に発生する現象です。

だから、「が＋（自動詞）」になります。

例四の中には、「人」がいます。

その人が「火を消しました」、これは人為的な行動です。

だから、「を＋（他動詞）」になります。

日文經常都會把「は」省略。
日本語の文章の中で、「は」はいつも略されます。

「今、何時ですか？（略）」
「今はまだ早いですわよ！（ある）」
「今日、友達と会います（略）」
「今日は早く起きます（ある）」

甚麼時候用「は」？甚麼時候省略？經常都會混淆。
因此，今次就圍繞著「は」說明一下。
どんな時は「は」をつけるか、どんな時は略すか、よく混同してしまいました。
なので、今日は「は」について詳しく説明してみます。

首先我要先弄清楚下面的大前提。
まず、以下のような前提から説明します。

在日文𥚃面，「は」並不是個必然的存在日本語の文の中に、「は」は必然の存在ではない
在文章𥚃面，可能存在著複數的「は」跟主語文の中には、複数の「は」や主語があるかもしれない

接著來看看下面的例子吧。
そして、下記の例文を見てみます。

例ー：今、何時ですか？

單純地問「現在」的時間是幾時，並不是要其他的時間滯。
単純に、「今」の時間が何時なのか、他の時間帯にかけていないです。

例二：今はまだ早いですわよ！

「現在」這個時間是「還太早」，但之後的時間不會還太早。
「今」は「まだ早い」だけと、その後は「まだ早い」ではないです。

例三：今日、友達と会います。

將「今日」特定出來，而不是昨天、前天、明天或後天。
「今日」という時間を特定にして、別に昨日、一昨日、明日、明後日のことではないです。

例四：今日は早く起きます。

只有「今日」是「早起」，不是「平常」也這樣「早起」。
「今日」だけに「早く起きます」。「いつも」と同じく「早く起きます」ではないです。

看到這𥚃多少能推敲出省略「は」的規則了。
就是想要把某時間特定出來時，我們就要加上「は」。
ここで「は」を略するルールがわかりました。
ある時間を特定することで「は」をつけます。

因此，還有這樣的例子。
だから、こいう例もあります。

例五：今日は綺麗ですね。今日「も」綺麗ですわよ！

並不只有「今日」，而是「每日」也很美麗。
「今日」だけではなく、「毎日」も綺麗ということを特定する意味です。

雖然是些基礎的東東，但過了這麼多年還是很容易犯錯。
為警惕自已，決定第一篇就寫寫「は」與「が」的分別。

1.「已知情報」vs「未知情報」

「が」一般是用來說明事情。
一般的に「が」の使い方は情報を説明することです。

例ー：冷蔵庫に刺身があるよ。

眼前能見到的、能聽到的事物客觀地進行描述。
目の前に見たり、聞いたりしたものことをより客観的に描写します。

例二：東京は日本の首都です。

雖然「は」也是用於說明事物，但不同之處在一個是「已知情報」而另一個是「未知情報」。
同じく情報を説明することですが、「は」と「が」の使い分けは「既知情報」と「未知情報」です。

例一的說話者是以對方不知道雪櫃𥚃面有刺身這件事為大前提的，而列二則是以「東京是日本的首都」這個人所皆知的常識為大前提來進行說明。
例ーの場合、話者は相手がその刺身が冷蔵庫にあることが知らないと仮定しました。例二の場合、「東京は日本の首都」ということは常識で、誰でも知っていると仮定しました。

２.「重點的位置」

例三：誰が田中さんですか？　その美人が田中さんですよ。

對於「是誰？」這個疑問，是以「田中先生」為特定對象而發出的問題。
亦既是說，這𥚃想要回答的不是某某的誰，而是說那個美人就是質問者想要知道的田中先生。
「誰なのか？」という疑問への答えは、「田中さん」という対象を特定するような意味があります。
つまり、他の人でもなく「田中さん」こそが「その美人」です。

例四：あの人は誰ですか？あの人は田中さんです。

「は」的情況正好相反，比起「田中先生」，這𥚃所特定出來的對象是「那個人」。
「は」をつける場合、「田中さん」という対象より、「あの人」ということを特定するような解釈があります。

根據「が」與「は」的使用，文章𥚃想要突出的重點也會不同。
就結果來說「が」所強調的都是前面的信息，而「は」則是強調後面的信息。
※　以「が」「は」來作文章的分界點「が」と「は」に対して、文脈次第で特定したい要点が違うと思いますが、結果的に「が」は前のことを強調することで、「は」は後のことを強調します。

３.「特定的話題」

還有，使用「は」的時候，通常都會有追加說明或額外的含意。
ちなみに、「は」を使う時、追加説明があるかもしれません。

例五：誰が好きですか？　田中さんは好きだけど、他に好きな人がいます。

對於「喜歡」這個話題，雖然表面上地說喜歡「田中先生」，但其實也不是想說喜歡「田中先生」，而是想追加說明「我有其他喜歡的人」。
「好き」ということを特定な話題にとして、別に「田中さん」という人が好きというわけではなく、「他の好きな人があります」という追加説明が強調します。
※　跟日本人談話時，要加倍小心理解文章的內容！別傻傻的忘記後面的追加說明才是最重要。

４．「比較」

當有兩個對象在進行比較時，比起上述的規則，一定會使用「は」。
二つ対象を比較する時、上記のルールより、「は」を使っています。

例六：妹は美人ですが、姉は美人ではないですね。

「妹妹」跟「姊姊」兩個對象以「美人」這個話題來進行比較。
「姉」と「妹」二つ対象を比較にして説明します。
そして、この二つの対象も同じく「美人」という話題に説明します。

Step 1) Blogger > 範本 > 編輯HTML

Step 2) 在<body>與</body>中間貼上以下的code

Step 3) <data:post.body/>後面貼上以下的code

1.「已知情報」vs「未知情報」

２.「重點的位置」

３.「特定的話題」

４．「比較」

About Author

Social Share Icons

Search Post

Popular Posts

Blog Archive

Label Cloud

About Us

Search Post

Step 1) Blogger > 範本 > 編輯HTML

Step 2) 在<body>與</body>中間貼上以下的code

Step 3) <data:post.body/>後面貼上以下的code

1.「已知情報 」vs「未知情報 」

２.「重點的位置」

３.「特定的話題」

４．「比較」

About Author

Social Share Icons

Search Post

Popular Posts

Blog Archive

Label Cloud

About Us

Search Post

1.「已知情報」vs「未知情報」