web-dev-qa-db-ja.com

mySQL UPDATEクエリが「0行に影響」を返す

私はこのクエリを持っています：

UPDATE phonecalls 
   SET Called = "Yes" 
 WHERE PhoneNumber = "999 29-4655"

私のテーブルはphonecallsです。PhoneNumberという名前の列があります。更新したいのは、Calledという列を "yes"に変更することだけです。

私が間違っていることは何か考えていますか？クエリを返すと、影響を受ける行は0と表示されます。

mysqlsql-update
19
user222427

アンフェタミンとYadaが示唆したように、あなたの電話番号が表にあるかどうか、SELECTで確認してください。

ただし、注意してください：問題の行のcalledの値がすでに「はい」の場合、mysqlは値を変更しないため、「影響を受ける行はありません」を返します。したがって、calledの現在の値も必ず確認してください

34
Dan Soap

私が観察した影響を受けた行が0になるもう1つの理由：間違ったデータ型。更新する列が整数またはブールで、文字列に設定した場合、列は更新されませんが、エラーも発生しません。

この投稿から他の戦略/アイデアを要約するには：

  1. SELECTステートメントを使用して、WHEREが機能し、結果を返すかどうかを確認します。
  2. 列に設定したい値がすでにあるかどうかを確認します。
  3. 目的の値が列のデータ型に適しているかどうかを確認します。
8
Thomas Puppe

ここにいるGoogleの誰にとっても、この問題は私がCONCAT()を使用して空のフィールドに追加しようとしたために発生しました。

_UPDATE example SET data=CONCAT(data, 'more');
_

dataがNULLの場合、CONCAT()はNULLを返し（2番目のパラメーターは無視されます）、値は変更されません（NULL値はNULL値になる）ため、0行が更新されます。

この場合、代わりにCONCAT_WS()関数に変更すると、問題が修正されました。

1
Malvineous

値が同じ場合、MySQLは行を更新しないため（警告またはエラーをトリガーせず）、影響を受ける行数は0になります。

1
Jimmy Adaro

問題は、PhoneNumber == "999 29-4655"のレコードがないことです。

このクエリを試してください：

SELECT * FROM phonecalls where PhoneNumber = '999 29-4655'

何も返さない場合、一致する行はありません。

1
ryanprayogo

私の場合、テキストの列を更新して、切り捨ての問題を修正しようとしていました。正しいテキストに更新しようとすると、0 rows updated行のテキストが変更されていなかったため。

正しい文字数に対応できるようにテーブル構造の列を拡張すると、目的の結果を確認できました。

0
Stephen Wylie
  1. 行が一致したと言っていますか：1変更：0警告：0？その後、おそらくその値にすでに設定されています。
  2. 一重引用符と二重引用符を試しましたか？
  3. 「999 29-4655」はスペース、スペース、またはタブであり、クエリとデータベースで一貫していますか？
0
goharma

それが私の提案です：

UPDATE `phonecalls` SET `Called` = 'yeah!' WHERE `PhoneNumber` = '999 29-4655' AND `Called` != 'yeah!'

また、テーブルとフィールドの名前は大文字と小文字が区別されることを確認してください。

0
Thiago Belem

select count(*) from phonecalls where PhoneNumber = "999 29-4655";を試してください。一致する行の数がわかります。結果が0の場合、データベースに一致する行はありません。

0
amphetamachine

これが何らかの結果を返すことを確認してください。

SELECT * FROM phonecalls WHERE PhoneNumber = '999 29-4655'

フィルターよりも結果が返されない場合WHERE PhoneNumber = '999 29-4655'は正しくありません。

0
Yada

このあいまいなケースに遭遇しました。このコードは、データベースからレコードのリストを読み取り、列を変更して、それらを1つずつ書き戻します。 UPDATEのWHERE句には、2つの条件WHERE key=? AND last_update_dt=?のみが含まれます。 （タイムスタンプチェックは楽観的ロックのためのものです。レコードを書き込む前に別のプロセスによってレコードが変更された場合、0行が更新され、エラーがスローされます。）

しかし、特定の1つの行でUPDATEが失敗したため、影響を受けた行はありませんでした。

何度も引っ張った後、行のタイムスタンプが2019-03-10 02:59であることに気付きました。米国のほとんどでは、そのタイムスタンプは存在しません。夏時間により、時間が2:00から3:00に直接スキップされます。したがって、MySQLからJava MySQLに戻る）の往復中に、コードの一部がそのタイムスタンプを他のタイムスタンプとは異なる方法で解釈し、WHEREにタイムスタンプを作成したと推測しました句が一致しません。

行のタイムスタンプを1時間変更すると、問題が回避されました。

（もちろん、正しい修正は夏時間を廃止することです。私はJiraを作成しましたが、米国政府はまだそれに対応していません。）

0
Bampfer